Subject: Server-side roles in the HTTP

From: "Mark Nottingham" <[email-masked]>
Date: Wed, 1 Sep 1999 09:44:07 +1000

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.

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.

The draft is available at:
http://www.ietf.org/internet-drafts/draft-nottingham-http-roles-00.txt
Please have a look at the references as well, as they help motivate the
document.

Any comments or help would be greatly appreciated. I'm particularly
interested in help with defining WebDAV PROPPATCH extensions that will allow
manipulation of HTTP-related metadata (such as Cache-Control and Expires
headers, and content negotiation hints).

Cheers,

--
Mark Nottingham, Melbourne Australia
http://www.mnot.net/

---

From: [email-masked] (Julien Pierre)
Date: Tue, 31 Aug 1999 18:51:46 -0700

Mark,

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

> 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