Re: Server-side roles in the HTTP

Mark,

Mark Nottingham wrote:

> As you may be aware, I have submitted an Internet-Draft,
> draft-nottingham-http-roles-00.txt.
>
> I'd very much appreciate comments from the http-wg, as I see it as primarily
> in that domain (with some overlap to wrec and the cgi efforts).
>
> I've already gotten a few comments, and I should make some clarifications.
>
> * The draft is an applicability statement, not a protocol specification.
> * My goal is to clarify responsibility for protocol implementation between
> servers, publishers, and facilities like CGI, PHP, NSAPI, ISAPI, Cold
> Fusion, etc.
> * Some of the measures it calls for will place some additional load on the
> server; this is an intentional decision. I believe that server vendors have
> sacrificed protocol compliance for benchmark speed, which in the long run
> doesn't do anyone any good.

Actually, in our case, it's less benchmark speed than backwards compatibility
with existing applications that has prevented  broader protocol compliance. You
will already see a lot more HTTP/1.1 features in NES 4.0, which should hit the
market RSN. It will still not be HTTP/1.1 compliant by RFC2616, but we made it a
much better-behaving server overall.

> This is probably a hard pill to swallow for server vendors; I understand
> that some of the things it calls for will be difficult to implement. I'd
> like to use the draft process as an opportunity to work them out.

Of the "Content-generation" mechanisms you cite above, some offer lower-level
access to the HTTP reply than others, and it's not necessarily feasible or
desirable to implement all your suggestions in all cases. For example, CGI is,
if limited, a high-level interface, and it's easy for the daemon to intercept
and process their responses. Then you have servlets (which you don't mention in
your paper), at a slightly lower-level. The servlet classes expose some HTTP
features so the complexity of intercepting and correcting content is greater.
Then you have server plug-ins which expose many low-level server internal
features and are more difficult to intercept in the daemon, as there are so many
server helper functions that can be called in many orders. Plug-ins can also be
more than content-generators - they may handle tasks like redirection and
authentication, which are also more difficult to correct on the fly in the
daemon.

For those applications that are strictly generating content, I think your
suggestions make sense. We came largely to the same conclusions recently before
I got a chance to see your draft, and we have even implemented some solutions to
these problems already; though you aren't likely to see the results until we
have a fully compliant HTTP/1.1 server.

As far as your draft, I think there should be fewer "MUST" requirements. For
instance, the partial content requirement won't necessarily fly with all type of
content generators. According to RFC2616 section 14.5, a server is not required
to serve ranges for all resources - it can send "Accept-range: None". That
doesn't preclude it from supporting ranges on other resources, such as static
files. I like this flexibility.

--
for a good time, try kill -9 -1