# MOO and HTTP

Paul Ezra Kautz (pek@llama.net)
Fri, 13 Sep 1996 09:51:01 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >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.