Question about "Trailer" header field

[Christophe JAILLET <ch...@wanadoo.fr>]

Hi,

I have a couple of question/remarks concerning trailer.
This came while looking around 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58177


Severals places in httpd seems to deal with RFC2616 13.5.1 End-to-end 
and Hop-by-hop Headers.
    Line 1211 of cache_util.c [1]
    Line 1311 and 1562 of mod_proxy_http.c [2]
    Line 3567 of proxy_util.c [3]


1) [1] is an exact copy of what is said in RFC2616 13.5.1
However, I wonder if the Trailers here, should not be a Trailer (without s)
Trailers (with a s) does not seem to a header field, just a keyword for TE.
Is this a typo in the RFC?


2) In [2] and [3], do some other headers should be listed and removed? 
(just as in [1])

I have not found anything equivalent and explicit in RFC7230 and co.



CJ

Re: Question about "Trailer" header field

[Yann Ylavic <yl...@gmail.com>]

Hi Christophe,

On Mon, Nov 2, 2015 at 11:29 PM, Christophe JAILLET
<ch...@wanadoo.fr> wrote:
>
> Severals places in httpd seems to deal with RFC2616 13.5.1 End-to-end and
> Hop-by-hop Headers.
>    Line 1211 of cache_util.c [1]
>    Line 1311 and 1562 of mod_proxy_http.c [2]
>    Line 3567 of proxy_util.c [3]
>
>
> 1) [1] is an exact copy of what is said in RFC2616 13.5.1
> However, I wonder if the Trailers here, should not be a Trailer (without s)
> Trailers (with a s) does not seem to a header field, just a keyword for TE.
> Is this a typo in the RFC?

I think it's rather a typo in the code, the relevant field is:
https://tools.ietf.org/html/rfc7230#section-4.4

(Note: the code in cache_util does not seem to handle the hop-by-hop
headers contained in the Connection header, like eg.
ap_proxy_clear_connection() does.)

>
>
> 2) In [2] and [3], do some other headers should be listed and removed? (just
> as in [1])

mod_proxy_http handles the response headers only, hence possibly not
exactly the same list as mod_cache (but with
ap_proxy_clear_connection() though).
Tranfer-Encoding is probably special too, since it may be required by
the output filters to determine how to forward the response.

>
> I have not found anything equivalent and explicit in RFC7230 and co.

RFC7230 Section 4.1.2 (referring to sections 4.3 and 4.4) is the
reference now (obsoleting RFC2616).

Regards,
Yann.

Re: Question about "Trailer" header field

[Christophe JAILLET <ch...@wanadoo.fr>]

Le 03/11/2015 00:00, Tim Bannister a écrit :
> On 2 Nov 2015, at 22:29, Christophe Jaillet wrote:
>> Severals places in httpd seems to deal with RFC2616 13.5.1 End-to-end and Hop-by-hop Headers.
>>    Line 1211 of cache_util.c [1]
>>    Line 1311 and 1562 of mod_proxy_http.c [2]
>>    Line 3567 of proxy_util.c [3]
>>
>>
>> 1) [1] is an exact copy of what is said in RFC2616 13.5.1
>> However, I wonder if the Trailers here, should not be a Trailer (without s)
>> Trailers (with a s) does not seem to a header field, just a keyword for TE.
>> Is this a typo in the RFC?
> With [1], I think you're right that this is a typo in RFC2616 which has been copied into httpd.
>
> [...]
>

Confirmed.

http://www.rfc-editor.org/errata_search.php?rfc=2616&eid=4522

CJ

Re: Question about "Trailer" header field

[Tim Bannister <is...@c8h10n4o2.org.uk>]

On 2 Nov 2015, at 22:29, Christophe Jaillet wrote:
> 
> Severals places in httpd seems to deal with RFC2616 13.5.1 End-to-end and Hop-by-hop Headers.
>   Line 1211 of cache_util.c [1]
>   Line 1311 and 1562 of mod_proxy_http.c [2]
>   Line 3567 of proxy_util.c [3]
> 
> 
> 1) [1] is an exact copy of what is said in RFC2616 13.5.1
> However, I wonder if the Trailers here, should not be a Trailer (without s)
> Trailers (with a s) does not seem to a header field, just a keyword for TE.
> Is this a typo in the RFC?

With [1], I think you're right that this is a typo in RFC2616 which has been copied into httpd.



As for [2] and [3], the Connection: header seems to be handled in mod_proxy_http.c (circa line 970). Transfer-Encoding: is likewise given special case handling (circa line 795). I can see a case for adding a comment to proxy_util.c explaining this.


That leaves Proxy-Authenticate: and Proxy-Authorisation: headers. Are these hop-by-hop?

It makes sense for a shared cache to delete Proxy-Authenticate: from a response, unconditionally. Similarly Proxy-Authorisation: from a request. The shared nature of cacheing brings obvious security issues.


https://tools.ietf.org/html/rfc7235 says “when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed” and “A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.”

So maybe there's an opportunity (enhancement request?) to make the forwarding of these headers configurable. I'm not sure what the default should be. I think the safe option, at least for trunk, is to remove those headers in the proxy code as well.


-- 
Tim Bannister – isoma@c8h10n4o2.org.uk