httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Nottingham <m...@mnot.net>
Subject Re: HTTP trailers?
Date Thu, 05 Aug 2010 00:49:09 GMT
Just to kick this discussion a bit;

The use cases that I've come across:

- adding debug / trace information to responses (e.g., how long it took, resource consumption,
errors encountered)
- adding a late-bound ETag or Last-Modified to the response (so that you don't have to buffer)
- adding Content-MD5 or perhaps even something cryptographically signed (ditto)

I've had discussions with a few browser folks who have shown interest in making trailers available
on their side (e.g., showing trace information in Firebug).

I don't agree that Apache should 5xx if trailers are set and they aren't able to be sent (e.g.,
because of a HTTP/1.0 client); the semantics of trailers in HTTP/1.1 are that they have to
be able to be ignored by clients anyway (unless TE: trailers is received in the request, which
IME is very uncommon). Dropping them on the floor is a fine solution -- as long as the code
inserting the trailers knows this.

In the long run, it would also be interesting to have Apache examine the TE request header
to determine whether trailers are supported; if they aren't, it could buffer the response
and put the trailers up into the headers transparently. Of course, large responses might make
this impractical, but in some cases it could be useful.

Finally -- HTTPbis gives us an opportunity to refine the design of trailers if there are issues.


Cheers,



On 24/04/2010, at 2:01 AM, William A. Rowe Jr. wrote:

> On 4/23/2010 10:25 AM, Brian J. France wrote:
>> 
>> On Apr 23, 2010, at 10:08 AM, William A. Rowe Jr. wrote:
>> 
>>> On 4/23/2010 9:03 AM, Brian J. France wrote:
>>>> 
>>>> You can build a module that is able to insert a trailer by adding a filter
and ap_hook_create_request call.
>>> 
>>> But doesn't this defeat the purpose of using a modular server
>>> architecture?  It seems this should be a facility of the core HTTP
>>> filter, if anyone wants to offer the patch for 2.3.
>> 
>> 
>> I agree, my module was more of a proof of concept that I can do it and then get some
other server to able able to use it.
> 
> :)
> 
>> Not sure what the best solution would be because multiple things need to happen.
 First part is you have to force chunk encoding either by removing content_length filter or
tweaking the code to not add it if doing a trailer (which you might not know until it is time
to insert a tailer).
> 
> Well, you also have to insert the 'Trailers' header, which must be known at the
> beginning of the request, so that becomes a simple trigger for dropping the
> content-length and forcing chunked encoding.
> 
> "If no Trailer header field is present, the trailer SHOULD NOT include any header
> fields" is a very explicit statement :)
> 
> This could be constructed from r->trailers_out, however users need to understand
> that after the beginning of the response, r->trailers out cannot be extended, only
> modified.
> 
>> Then you have to tweak modules/http/chunk_filter.c to allow others to insert a trailer,
like adding a ap_hook_http_trailer or a optional function for inserting it.  I don't know
if multiple modules should be allowed to add a trailer, if you do how to you join them since
a trailer is nothing but a string ending with ASCII_CRLF (just strcat?).  Should we just grab
r->notes['http_trailer'] and let modules just add/set/append values?
>> 
>> I think there is a bigger design discussion that should happen, but I might have
a patch down the road as a starter if all goes well at work.
> 
> These pieces seem more like implementation details.


--
Mark Nottingham     http://www.mnot.net/


Mime
View raw message