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/
