httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: new ETag supression/weakening API
Date Tue, 16 Dec 2003 02:09:07 GMT


Roy T. Fielding wrote:
>> one of the issues that needed working out was dealing with multiple ETag
>> headers.  my original idea was to have ap_weaken_etag guarantee that ETag
>> headers would be weak.  with ETag headers entering err_headers_out via a
>> third party, there exists the possibility that the server would send
>> multiple ETag headers for a single request.  while I'm not sure if
>> this is
>> actually legal, I can't find anything that says it isn't.
> 
> 
> RFC 2616, section 3.11, BNF does not allow multiple ETag header fields.

excellent, thanks.

> 
> I think you need to work on making this patch more efficient -- it is
> doing too much work for an activity in the critical path of servicing
> a request. 

yes, it certainly felt that way.  but now that you've cleared up the
multiple header bit, lots of that excess can get cleaned up.

> BTW, an entity tag does not identify the entity -- it merely
> acts as a key for cache and range request handling.  

right.  and what I was trying to do was make it possible for
content-altering filters to handle that key a bit more intelligently than
just removing it altogether.  the situation I initially had in mind was when
a filter was bitwise altering the content but not the semantics of it, an
HTML scrubber perhaps.  in this case, it seems that allowing the default
ETag is wrong, but that removing it can be avoided (thus keeping to the
spirit that ETags should be sent if feasable).  granted, the circumstances
are probably very rare that filters would behave that way.  are you saying
that weakening the ETag is the wrong behavior here?  if so I'm kinda wasting
my time (as well as everyone else's).


> If a filter
> consistently produces the same content, then it should not modify the
> entity tag (the routine that arranges the filters must do that if needed).

hmm...  I don't see how that would work given the current API.  but it does
seem like the API could be a bit better.  perhaps filters could supply
criteria that ap_make_etag can draw from when the time comes.  is that what
you had in mind?

anyway, thanks for taking the time to clear things up and offer a bit of
advice.  I appreciate it.

--Geoff



Mime
View raw message