On Fri, Oct 25, 2013 at 9:12 AM, Yann Ylavic <[email protected]> wrote: > On Thu, Oct 24, 2013 at 7:42 PM, Eric Covener <[email protected]> wrote: >> >> On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic <[email protected]> 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?
yes, that's fine. > > 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 > hop-by-hop). > 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) > r->trailers_in/out... > > 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)? Generally would consider it as it goes into trunk, and jump through some level of hoops to keep them common when possible. > > 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... +1 -- Eric Covener [email protected]
