Re: Server-side roles in the HTTP

Julien,

Thanks for taking the time to comment.


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

Good point; I'm fairly ignorant of the inner workings of servlets as well as their newer cousins like JSP. They very well may fall out of scope for this 
proposal. However, I think that would be a shame; even people with the knowledge to use these facilities rarely implement anything beyond the very 
basics of the protocol.

There's nothing in the draft (although this isn't articulated well) that says mechanisms can't be established to override these server-level responsiblities. 

What I'm trying to do is give the people I called 'publishers' the assurance that, if they use a server and generator compliant with this draft, they won't 
need to worry about details of protocol implementation -- not that they do (that's the root of the problem). 

Whether the server or the 'content generators' is the best place to do that is an interesting question; my feeling is that it's simpler and more reliable to do 
it in the server.


> 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

It does become a nightmare if it is applied to everything that can be tied into a server. It may be prudent to draw a line at APIs, or perhaps there needs to 
be a further distinction in the draft - 
* content generators (CGI, PHP, ASP, etc) - have a 'shallow', high-level view into the server, server is required to handle all protocol features (as in current 
draft)
* APIs et al (Servlets, ISAPI, NSAPI, etc) - low-level 'deep' view, api user has library of protocol feature calls available

Would this be more practical?


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

Can't wait!

 
> As far as your draft, I think there should be fewer "MUST" requirements.

It depends on how you place the draft. If you think of it as a peer document to 2616 (you must be compliant with this draft to be considered HTTP 
compliant), you're right - it's far too strict. However, if you consider it as an additional, higher level of compliance, the MUSTS are important. 

I do think that some of the SHOULDs (especially to do with buffering and *perhaps* synthetic validation) might be better as MAYs.


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

But from a protocol/network/user perspective, does it make any sense that a feature is available for one resource but not another, based on the 
underlying technology? If you have a PDF file that happens to be generated by a CGI script, it's a huge pain to get it to support ranges, validation and 
other facilities in the script itself. I've done it, and it was not pleasant. 

A lot of the feedback that I've gotten has been in this vein - that not every object is going to take advantage of all of these 'extra' services. But, if they 
aren't available by default, chances are they'll never be thought of, much less handled.

The other way that I'm working on attacking this problem is creating a series of wrapper scripts / libraries that will take care of as much of this stuff as 
possible automatically. Unfortunately, it's very much an uphill battle (for instance, if I include a content-length in Netscape or Apache CGI, it will make the 
connection persistent; no such luck with other servers), so this would only be a temporary measure. 


Cheers,

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

Received on Saturday, 4 September 1999 13:55:27 UTC