httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: non-forking wish list
Date Sun, 11 Jun 1995 19:33:39 GMT
   Date: Sun, 11 Jun 1995 14:59:30 -0700
   From: "Roy T. Fielding" <>

   > (Note the Apache-internal "protocol" specifier, which should hopefully
   > distinguish these now and forever from any legitimate form of HTTP).

   Why?  HTTP was designed to handle arbitrary methods -- the HTTP/1.0
   just indicates the message format.

Well, see subsequent email for why I'm not sure that sending requests
to port 80 is the best way for the server and its monitoring software
to communicate anyway.  But to answer the question, I wanted to make
the distinction clear for a couple of reasons:

1) Avoiding namespace pollution.  If we wire a rich enough set of
   status inquiries into the server, and make them all look basically
   the same as ordinary requests, sooner or later someone is going to
   unknowingly try and use one of the reserved names for a more
   ordinary piece of data.  That risk could be minimized by making the
   requests in question look less like normal HTTP requests than they
   might otherwise, e.g., by disguising them as proxy requests for a
   bogus protocol, as in your suggestion:

       GET apache:performance HTTP/1.0

   but that leaves the other problem...

2) While HTTP was designed to handle arbitrary methods, it does lock
   us into a request/response paradigm.

   At some point we may want to do something which conflicts with that
   paradigm.  For instance, suppose we want the server to periodically
   report the state of a select set of variables, without the monitor
   having to intervene, but we also want the monitor to be able to
   change the set of reported variables at will.  With HTTP-NG
   predictive requests, I can see at least one possible approach to
   shoehorning it into the protocol (the server "predicts" that the
   monitor is still interested in whatever it asked for most recently)
   but for HTTP/earlier-than-that, I can't see any easy approach.

   Since interoperability with other HTTP-aware entities is explicitly
   not a concern here anyway (this is about how one hypothetical piece
   of our own software might talk to another part), it may be best to
   avoid confusion by making a clean break from the outset.


View raw message