W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

Re: Server-side roles in the HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 21 Sep 1999 20:50:21 +1000 (EST)
To: Julien Pierre <jpierre@netscape.com>, http-wg@hplb.hpl.hp.com
Message-Id: <19990921105021.2FF8DC4F0@mail.mnot.net>
Quoting Julien Pierre <jpierre@netscape.com>:

> However, with a large dynamic object and the approach you suggest, these
> benefits would be effectively negated since the application would have to
> run multiple times instead of one. 

This would only be true for PDFs and other non-sequential access methods, not file download resumption, etc. 

> Instead of implementing some relatively complex
> code to handle it transparently which would have questionable value and
> performance, I would be much more inclined to have the server add an
> "accept-ranges: none" by default for CGIs and other applications so that
> this situation would not happen.
> Of course, this would be done only if the application doesn't insert its
> own Accept-ranges to indicate that it can handle it.

Well put. I'm not particularly interested in fighting for partial content; it has limited uses and is a pain to implement in caches (which is the prime area of 
interest for me). How about something along the lines of servers MAY handle ranges transparently, but if they don't, they MUST send Accept-Ranges: 
none, unless the content generator has set an Accept-Ranges?

The other way to approach it would be to default to no ranges, allow the generator to communicate that it can handle them, and allow the generator to 
dictate to the server that it should handle them (by regenerating content, if they server implementor has chosen to do this). Hmm, his seems a bit 
unwieldy...


> If it's purely the identity then it is only an authentication scheme.
> In the case you described previously, it sounds like your CGI script was
> not really generating content but only providing authentication.
> 
> To handle such cases, there are much better ways :
> - use LDAP ACLs if your users are in an LDAP server . That's the easiest
> way - no programming required
> - use a server plug-in to do your own authentication for a resource

In this particular case, I was charged with making a CGI application's output (PDFs) cacheable, without changing it; there was a lot
of logic in determining the authentication criteria, and the implementors did it in CGI, because it seemed natural for them to do so. There's a fair amount 
of this sort of thing going on; people don't really think about the protocol-level implications of what they do.

I'm on holiday right now (in an internet cafe in London), so I won't be reading my mail too often. However, I do plan to submit a revised draft incorporating 
a lot of what's been discussed when I get back, and hopefully this can be discussed in Washington.


--
Mark Nottingham
http://www.mnot.net/
Received on Tuesday, 21 September 1999 11:50:31 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:34 EDT