Re: Server-side roles in the HTTP

Hi, Mark!

Sorry for the delay in answering - things can be a bit busy at times.

Mark Nottingham wrote:

> I agree to some extent. I need to make it more clear that the draft is about
> defaults; in this case, if you have a more efficient way of handling range
> requests in the CGI, have it generate a 'Accept-Ranges: bytes' header, and
> the server should know that the application is capable of dealing with
> partial content. Best of both worlds.

Noted. This adds some extra complexity again, but it should work.

> Even if this isn't taken advantage of, IMHO it's much easier to scale a
> server (hardware) than the complete network between any possible user and
> the server. Regenerating the entire object to send a few bytes is
> inefficient on the server, but it's better than leaving it in the
> publisher's hands; as in most cases it won't be done at all.

I'm not sure that it's better to have it done this way as opposed to not having
it done at all.
Partial content was designed to provide faster access to the needed data, thus
improving performance.
These benefits are particularly evident with large objects.

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

> I'd very much like a survey to be done of Webmasters, CGI scripters, etc.,
> to ask them where they think the responsibilty for handling these features
> currently lies.

I don't think we need to do such a poll to know the results :-).
Even though it sounds nice to have ranges for CGIs, my take as a server
implementor is that having it done transparently in the server is at best not
going to help and in most cases will hurt performance both on the server and
client sides.

> > Ranges work best with direct access content (eg: static files) or with
> cacheable content ; with dynamic content, the server typically only has
> sequential access to
> > the content and does not cache it.
>
> I know what you're getting at, but I really want to redefine what people
> think of as dynamic content, as well as cacheability.
>
> Dynamic content to me is defined by dependence on either the identity
> (however derived) of the current user,

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

If on the other hand the bits of the PDF were generated on the fly, let's say
from the user input, then the CGI might make sense.
But I wonder how the PDF plug-in deals with POST when it makes its partial
content requests .. It would have to repost the whole
user input for every range request. You can see how inefficient that is - no
matter if it's the server or the CGI script that handles the range.

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