W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: I-D draft-petersson-forwarded-for-01.txt

From: Darrel Miller <darrel@tavis.ca>
Date: Tue, 11 Oct 2011 01:37:10 +0000
To: <ietf-http-wg@w3.org>
Message-ID: <0e1301cc87b6$322847c0$9678d740$@tavis.ca>
Inline.

Andreas Petersson wrote 
> I was not aware of draft-saintandre-xdash when I wrote this draft.
> It seems appropriate to include a reference to this.
> As draft-saintandre-xdash is only a draft yet, how can I update
> draft-petersson-forwarded-for to take this x- deprecation into account?
> Suggested formulations are welcome.

I would second Martin Thomson's suggestion that you just don't mention it.

> Darrel Miller wrote
>> Also, it would be nice to have a "from" parameter, as alternative to the
>>From Http header, that allowed the use of a URN to identify the requesting
>> user rather than being limited to an email address.
>> 
 Andreas Petersson wrote  
>I don't see the usecase for it, containing an URN.

It is often the case that an origin server that returns a composite resource
may authenticate a user and then make a request on behalf of that user to a
second server that wishes to log the identity of the user.   The origin
server may not have access to the email address of the requesting user.  The
best it can do is use some identifier based on the authentication
credentials.  A URN seemed like the most generic type of identifier we could
use.

The current alternatives for this situation as I see them are: 
1) use the Http From header and ignore the requirement to be an email
address
2) use the Http From header and create a fake email address that can be
parsed to identify the user
3) use some custom header for the purpose. 

When I read your spec it seemed a good opportunity to be able to address
this scenario.

>More important, I don't think it
>would be appropriate to divert the semantics, or syntax of the field
>from the definition in RFC2616 / draft-ietf-httpbis-p2-semantics.

Yes, I understand the danger in having the Forward: from have different
requirements than the Http From but that is also the advantage, in that we
have a chance to provide a capability that was previously unavailable.
Unless I am missing a more obvious solution.

Darrel Miller
Received on Tuesday, 11 October 2011 18:33:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT