httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: stop copying footers to r->headers_in?
Date Fri, 25 Oct 2013 13:12:00 GMT
On Thu, Oct 24, 2013 at 7:42 PM, Eric Covener <> wrote:

> On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic <> wrote:
> >> 1) add r->footers_in and use it in 2.2 and up by default
> > Do that mean no API/ABI change ?
> In the sense that it needs to be backportable, yes -- but it will mean
> a behavior change to "existing" APIs. Depends on how you interpret it
> I guess, but I think the confusion over trailers/headers is something
> that needs to be forcible corrected in those service releases.

Concretely, is request_rec::trailers_in/out (at the very end of the struct)
something backportable or should the footers be stored elsewhere?

According to [my understanding of] the rfc2616 and/or
draft-ietf-httpbis-p1-messaging-24 about the HTTP trailer (chunking, TE and
Trailer sections), they are hop-by-hop (anyway negociable/negociated
They could then be stored in something more related to the request's
connection(s), for *example* in the http_ctx_t used by ap_http_filter for
input, which could probably be shared with protocol output filters too for
the trailers_out.
There is still the need to access them from r, for *example* (still) with
something like the request_config of the http_module.
But this looks like a big hack compared to the (simple)

So, is the backportability something to care about for trunk (now) or
things should be kept [as] simple [as possible] there and complications
arise when backporting (using a different storage/access for example)?

My plans were to use request_rec for now and change this later if it oughts
to, but it could be useful to point/suggest me a backportable way for that
before I hit the wall...

> Thanks again for the help!

And you for your feedbacks.


View raw message