Re: The document's address

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: The document's address

Ian Hickson
On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>
> The definition of the document's address:
> http://dev.w3.org/html5/spec/dom.html#the-document's-address
> doesn't mention if the Content-Location header should be taken into account.

My understanding is that Content-Location is essentially dead:

   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: The document's address

Julian Reschke
On 2013-01-17 20:49, Ian Hickson wrote:
> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>
>> The definition of the document's address:
>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>> doesn't mention if the Content-Location header should be taken into account.
>
> My understanding is that Content-Location is essentially dead:
>
>     http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154

It's not dead at all, it just lost the base-URI-setting semantics.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: The document's address

Nicholas Shanks-2
In reply to this post by Ian Hickson
On 17 January 2013 19:49, Ian Hickson <[hidden email]> wrote:
> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>
>> The definition of the document's address:
>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>> doesn't mention if the Content-Location header should be taken into account.
>
> My understanding is that Content-Location is essentially dead:
>
>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154

That ticket says:

"2) HTTP's advice to set Content-Location when doing server-driven
content negotiation results in links that are relative to a negotiated
resource, rather than the desired (non-negotiated) URI."


I find this is a real pain and wish I could turn it off in Apache. I
only want Content-Location to be present when I intend it to be, e.g I
want to do this:

POST /collection-uri
{ representation of new resource }

201 Created
Content-Location: /resource-uri
{ representation of created resource }

and have caches and the address in the browser's address bar use the
given Content-Location for the representation returned, not use the
request URI.


But instead I have to do this:

POST /collection-uri
{ representation of new resource }

303 Go Here
Content-Location: /resource-uri

GET /resource-uri

200 OK
{ representation of created resource }


requiring an extra round-trip and losing the semantics of a 201
response. If HTTP could be changed so that content negotiation MUST
NOT cause C-L: header to be added, and HTTP software patched to obey
this, then there may be scope in the future for requiring UAs to
display the Content-Location rather than the request URI, once servers
have had their software updated. HTTP 1.x may be a lost cause, but
there is still time to fix it for 2.0

--
Nicholas.

Reply | Threaded
Open this post in threaded view
|

Re: The document's address

Roy T. Fielding
On Jan 18, 2013, at 3:46 AM, Nicholas Shanks wrote:

> On 17 January 2013 19:49, Ian Hickson <[hidden email]> wrote:
>> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>>
>>> The definition of the document's address:
>>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>>> doesn't mention if the Content-Location header should be taken into account.
>>
>> My understanding is that Content-Location is essentially dead:
>>
>>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
>
> That ticket says:
>
> "2) HTTP's advice to set Content-Location when doing server-driven
> content negotiation results in links that are relative to a negotiated
> resource, rather than the desired (non-negotiated) URI."
>
>
> I find this is a real pain and wish I could turn it off in Apache. I
> only want Content-Location to be present when I intend it to be, e.g I
> want to do this:
>
> POST /collection-uri
> { representation of new resource }
>
> 201 Created
> Content-Location: /resource-uri
> { representation of created resource }
>
> and have caches and the address in the browser's address bar use the
> given Content-Location for the representation returned, not use the
> request URI.

Which would be a security hole if /collection-uri and /resource-uri
are controlled by different owners.  In practice, there is no way
for clients to know the scope of resource ownership.

Search for "cache poisoning" for more explanation.

> But instead I have to do this:
>
> POST /collection-uri
> { representation of new resource }
>
> 303 Go Here
> Content-Location: /resource-uri
>
> GET /resource-uri
>
> 200 OK
> { representation of created resource }
>
>
> requiring an extra round-trip and losing the semantics of a 201
> response. If HTTP could be changed so that content negotiation MUST
> NOT cause C-L: header to be added, and HTTP software patched to obey
> this, then there may be scope in the future for requiring UAs to
> display the Content-Location rather than the request URI, once servers
> have had their software updated. HTTP 1.x may be a lost cause, but
> there is still time to fix it for 2.0

Not likely in either case,

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: The document's address

FOURNEL Alexandre
For more info on cache poisoning : http://packetstorm.igor.onlinedirect.bg/papers/general/whitepaper_httpresponse.pdf (31 pages) or https://www.owasp..org/index.php/Cache_Poisoning


"To successfully carry out such an attack, an attacker:
  • Finds the vulnerable service code, which allows them to fill the HTTP header field with many headers.
  • Forces the cache server to flush its actual cache content, which we want to be cached by the servers.
  • Sends a specially crafted request, which will be stored in cache.
  • Sends the next request. The previously injected content stored in cache will be the response to this request.
This attack is rather difficult to carry out in a real environment. The list of conditions is long and hard to accomplish by the attacker. However it's easier to use this technique than Cross-User Defacement.
A Cache Poisoning attack is possible because of HTTP Response Splitting and flaws in the web application. It is crucial from the attacker's point of view that the application allows for filling the header field with more than one header using CR (Carrige Return) and LF (Line Feed) characters."


Good conversation so far, thanks!

-Alexandre FOURNEL • Fire Starter!

-Connect with me on:

-Projects:



On 18 Jan 2013, at 13:23, Roy T. Fielding wrote:

On Jan 18, 2013, at 3:46 AM, Nicholas Shanks wrote:

On 17 January 2013 19:49, Ian Hickson <[hidden email]> wrote:
On Wed, 21 Nov 2012, Nicholas Shanks wrote:

The definition of the document's address:
http://dev.w3.org/html5/spec/dom.html#the-document's-address
doesn't mention if the Content-Location header should be taken into account.

My understanding is that Content-Location is essentially dead:

 http://trac..tools.ietf.org/wg/httpbis/trac/ticket/154

That ticket says:

"2) HTTP's advice to set Content-Location when doing server-driven
content negotiation results in links that are relative to a negotiated
resource, rather than the desired (non-negotiated) URI."


I find this is a real pain and wish I could turn it off in Apache. I
only want Content-Location to be present when I intend it to be, e.g I
want to do this:

POST /collection-uri
{ representation of new resource }

201 Created
Content-Location: /resource-uri
{ representation of created resource }

and have caches and the address in the browser's address bar use the
given Content-Location for the representation returned, not use the
request URI.

Which would be a security hole if /collection-uri and /resource-uri
are controlled by different owners.  In practice, there is no way
for clients to know the scope of resource ownership.

Search for "cache poisoning" for more explanation.

But instead I have to do this:

POST /collection-uri
{ representation of new resource }

303 Go Here
Content-Location: /resource-uri

GET /resource-uri

200 OK
{ representation of created resource }


requiring an extra round-trip and losing the semantics of a 201
response. If HTTP could be changed so that content negotiation MUST
NOT cause C-L: header to be added, and HTTP software patched to obey
this, then there may be scope in the future for requiring UAs to
display the Content-Location rather than the request URI, once servers
have had their software updated. HTTP 1.x may be a lost cause, but
there is still time to fix it for 2.0

Not likely in either case,

....Roy