MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: MOO and HTTP


>On Wed, 11 Sep 1996, Cheng Soo Yin wrote:
>>         I am seeking for someones out there who had implemented the MOO-HTTP
>> server or likewise. Please kindly share with me your precious experiences.
>> Alternatively, you may like to give me some pointers and these are mostly
>> welcome. I will like to discuss with those who are interested in this area.

Colin McCormick wrote, much to the dismay of Colin McCormack:
>solution I've used is to write a builtin function uudecode() (the guts of
>which are stolen from the Apache server) but I'll bet there's someone out
>there who's implemented uudecode in-MOO.  (Anyone?) Either way should

Yeah, JHM did.  I'd call it 'base64' or 'PEM Encoding' rather than
'uudecode', though.  While uuencoding supports some sort of base64,
it has control info etc.  Anyway, this is specified in RFC 1521, 
I think.  The gist is that you take three normal 8-bit characters 
and represent them over four base64 digits.

JHM is jhm.ccs.neu.edu 1709.

>3) The Interactive Method

If this post were a silent movie, this is where the accompanyment score
would call for a dramatic dance-along-the-evil-keys.

>The final method I know about (and the one I'm most interested in) is
>probably something this list has heard too much about from me ( :) ) but
>I'll mention it quickly here.  

>As I said above, "do_login_command" is called for each line of input from
>a new connection, with that line as its argument.  If "do_login_command"
>returns a valid player object number, the connection is logged in as that
>player.  It is possible to have "do_login_command", each time it is
>called, save its string argument to some convenient property (or even as
>Gustavo cleverly suggested into the ".flush" connection option) until it

Or you could just parse the headers progressively, as I do.  This
fails in that you still have to keep track of the last header read,
because of that stupid allowance in the spec that lets people continue
header values on the next line prepended by whitespace.  But it's
still easier than parsing everything at once.

>detects the last line of an HTTP request.  (Usually an empty line
>immediately preceded by a line starting with "Content-length: X".)

As Andy Bakun mentioned, this isn't so; "Content-length" can be
anywhere among the request headers.  You'd look for the blank
line that follows the headers.  However, in the case of some request
methods (eg POST) this isn't the end of the request.  What follows
the headers is the request entity.  For GET and friends it is
just empty.

This is where MOO gets a bit hung up in theory, because the request
specifies the "Content-length" to recv(), while MOO just looks at
incoming data line-by-line.  In practice, this isn't a problem, because
x-www-form-urlencode -- the form return format in use today -- will,
for a POST request, put it all on one line followed by the usual CRLF.

>authenticate correctly, return a valid player object.  The connection is
>now "logged in", and will appear to other players in the MOO as a normal
>player.  If this is combined with the trick of *not* sending the final
>"boot_player()" line in the code snippet from Method (1), the connection
>from the MOO server to the HTTP browser will be kept open, and other
>players can say/emote/etc. anything to the player who is connected via the
>Web browser. 

>This becomes particularly exciting if your URL protocol has some way of
>specifying commands to be entered as MOO commands, i.e.
>  http://moo.myhome.org/command/say+hello
>Then the GET/POST/HEAD verb (wizard-owned) can use force_input() to make
>those commands be entered as if the browser-connected player had typed
>them via a normal telnet connection.  Voila: interactive Web Browsing! 
>(And state-maintaining HTTP, because you can save any data you want to
>about a player in the MOO database.)

Wow, what a convolution!  Sorry, it just doesn't get me excited.

I'm sure you've already heard this, so I say this to the original
poster: HTTP/1.0 is not designed to be interactive.  It is a one-request,
one-answer protocol, designed for accessing parts of the World Wide Web,
which I at least think of in terms of units called 'documents.'
Don't let the quirks of one bloated monopolistic browser lead you
to think that HTTP/1.0 supports anything like persistant connections,
much less the dreaded 'server push'/'client pull.'

HTTP/1.1, if it becomes standard (or maybe it already has?), has
tools built-in for maintaining a persistant connection, which would
ease some of your 'state-maintaining', but it is still grossly
inefficient in that for each request, often several kB of headers
are sent, and for legal HTTP/1.1 your output would need to be
in some form of 'chunks', which require more headers, and so on.

>I actually have been having a lot of luck with this approach, and would be

That's the problem.  It "works," so lazy people want to use it.
People too lazy to create a real interaction protocol and set of
tools.  I've been fighting this for two and a half years; please
don't listen to Mr. McCormick.  The combination of an extendable
mud and HTTP is excellent for a dynamic web server, but the MOO
will not bring you "interactive Web browsing"; it'll bring pain
and suffering to all humanity.  It doesn't really "work" because
it brings in much more problems than solutions and it impedes
the progress of an actually constructive protocol.

My advice to the original poster: yes, read the MOO programmer's
manual.  But also read the HTTP/1.0 spec (you can find it from
<http://www.w3.org/>) and the standard of any other protocol you
intend to implement.  Second-hand information like what we are
giving you isn't always reliable.

Paul Kautz

PS  Notice how the double quote-marks are scarier than the single ones.
References:
Home | Subject Index | Thread Index