httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: stop copying footers to r->headers_in?
Date Fri, 25 Oct 2013 13:16:30 GMT
On Fri, Oct 25, 2013 at 9:12 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Thu, Oct 24, 2013 at 7:42 PM, Eric Covener <covener@gmail.com> wrote:
>>
>> On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic <ylavic.dev@gmail.com> 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
covener@gmail.com

Mime
View raw message