W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Working Group Last Call: draft-ietf-httpbis-auth-info

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 02 Mar 2015 02:01:12 +1300
Message-ID: <54F30D98.2070602@treenet.co.nz>
To: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
On 2/03/2015 1:52 a.m., Julian Reschke wrote:
> On 2015-02-11 11:10, Amos Jeffries wrote:
>> On 11/02/2015 9:43 p.m., Julian Reschke wrote:
>>> On 2015-02-11 02:37, Amos Jeffries wrote:
>>>> On 11/02/2015 11:59 a.m., Mark Nottingham wrote:
>>>>> Everyone,
>>>>>
>>>>> Julian believes (with his editor hat on) that this is ready. As
>>>>> discussed, this is a simple document to pull the Authentication-Info
>>>>> and Proxy-Authentication-Info header fields out of 2617, so that
>>>>> they’re not associated with a particular authentication scheme
>>>>> (thereby avoiding lots of scheme-specific headers).
>>>>>
>>>>> Therefore, this is the announcement of WGLC for:
>>>>>    https://tools.ietf.org/html/draft-ietf-httpbis-auth-info-02
>>>>>
>>>>> Please review the document carefully, and comment on this list.
>>>>>
>>>>
>>>>
>>>> Section 3 paragraph 3 says "
>>>>    Intermediaries are not allowed to modify the field value in any way.
>>>> "
>>>>
>>>> RFC 7235 uses wording in the form:
>>>>     A proxy forwarding ... MUST NOT modify ...
>>>>
>>>> I believe the Authentication-Info should share both normative MUST NOT,
>>>> and term "proxy" instead of intermediary. Since there are legitimate
>>>
>>> Right now the spec doesn't use any RFC 2119 terms, so if we do this,
>>> we'd need to apply it in more places.
> 
> I'll track this separately as
> <https://github.com/httpwg/http-extensions/issues/52>.
> 
>>>> cases where gateways and/or other intermediaries may need to change it
>>>> per the relevant auth scheme.
>>>
>>> Can you give an example?
>>>
>>
>> 1) A gateway which is itself the client doing the authentication to the
>> origin needs the ability to strip the header it caused to exist.
>>
>> 2) An ESI gateway transforming the payload from multiple transactions,
>> only some of which are authenticated, or authenticated using different
>> schemes. Needs the ability to filter which (if any) the client gets
>> delivered.
>> ...
> 
> Tracked as <https://github.com/httpwg/http-extensions/issues/50>;
> proposed next text:
> 
>    A proxy forwarding a response is not allowed to modify the field
>    value in any way.
> 
> (see
> <https://github.com/httpwg/http-extensions/commit/e175586ede472946b1428bb355c3195b21cdf06b>).
> 
> 
> Does this work for you, Amos?

Yes.

Amos
Received on Sunday, 1 March 2015 13:02:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC