Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*

• Date: Sun, 4 Aug 1996 18:54:32 PDT
• From:
  Richard Connamacher <phantom@sfsu.edu>
• cc: Colin McCormick <colin@tripod.tripod.com>, moo-cows@parc.xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <199608041916.PAA07953@k2.ccs.neu.edu>

On Sun, 4 Aug 1996, Jay Carlson wrote:

> > First to say that I think a connect_player() / bind_connection() builtin 
> > function would be a good idea and a nice step in making the database more 
> > independant of specific server nuances.  I do, though, have to disagree 
> > with both of the reasons posted.  First, HTTP is by definition supposed 
> > to be _stateless_, which means that logging someone into a MOO through a 
> > web connection is actually against the HTTP specifications.
> 
> The HTTP protocol spec sez very little about implementation (aside
> from cautions about what you need to do to interoperate with
> wide-spread busted implementations).  It's really none of the spec
> writer's business how I choose to implement it, as long as what's
> externally visible is ok.

Perhaps I came across wrong in my post.  I'm all for hacking with HTTP to 
come up with new and cool uses for it.  If, however, you're going to call 
it an HTTP server and expect it to work with all HTTP clients, it has to 
be made within the guidelines of the HTTP specs.  For example, say you 
made a URL, http://moo.foobar.net:4242/player/say/Hello%20There.  Someone 
could call this hacking, using HTTP to create new interfaces.  In 
practice, though, you'll have to face the wrath of the HTTP world with 
proxies that assume you follow the http specs will be hitting that url 
over and over again to see what it does.  If it's going to be called 
HTTP, it should be HTTP. :-)

> 
> JHM's web gateway happens to log in HTTP connections by creating a new
> kid of $httpd.generic (well, modulo Ken's beautiful web handler
> objects, but).  With a fair amount of work, we could make it use
> unlogged in connections too, and provide exactly the same result.  I
> can't see how a specification would outlaw our choice.

Ok.  I don't see how a spec would be against that choice either.  I was 
under the assumption that, by logging in HTTP connections, the author 
intended to have the connection the main logged in connection.

> > You must be confusing the unix ftp client, where it prompts you for a 
> > password and you type it in, and the actual interface to the FTP server, 
> > where "PASS" _is_ a command, of the form PASS <password>, which is 
> > supposed to follow a USER <username> command.  In MOO, if you really 
> > wanted to make the main interface via FTP, then you'd log someone in 
> > simply by returning the player's object number after the PASS command 
> > gets executed.  Running a read() after the USER command gets executed is 
> > not only unneccessary, but probably also against the FTP protocol specs 
> > where PASS is a command and only a command.
> 
> Same response.  Although I haven't stared at the RFC for ftp lately, I
> would be positively stunned if it dictated implementation choices.

I haven't studied the rfc, so I don't know if it dictates when the PASS 
command should be executed (ie says that it must be run directly after 
the USER command is run or not), but as long as it doesn't say that the 
PASS _must_ follow the USER, then any server that assumes it would could, 
with some clients, get confused when it doesn't.  That's why I said that 
it would probably be best and most FTP-spec-friendly to make it just 
another command.

> Let me rephrase this: don't extend the HTTP protocol to include
> dialog; if you must, don't call the result HTTP.

Amen, brother.  Amen.  :)

Phantom

• Prev: Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• Next: Re: bf_connect_player(CONN, PLAYER) --> *FTP!!*
• Index: MOO-cows
• Thread: MOO-cows