Re: How to identify existing resource in a POST(a) request

Mike,

Hi - thanks for responding.

In this instance I'm not sure I fully agree...

When following a bookmark, the default goal is a GET.  This is reasonable in that a bookmark contains the URI, but lacks semantic information (the "rel") with which to understand anything more.  The default behaviour of a user-agent is therefore "I'll GET the resource and go from there".  In a hyperlink context, as we understand, the goal (as educated by the "rel") can be and generally is more complex.

My point here is not that the "Referer" is a general solution that I could / should be dependent on in all scenarios, but that it provides the origin server more information (in a standardised way) about the context in which a hypermedia link has been followed - enriching the request semantics if you will.  In some cases this would be useful, and perhaps preferable to the requirement for a "self" link in the representation.

With regards to the user-agent issue -> fix user-agent!

With regards to the security concern I don't really see how *using* the Referer header instead of a "self" link provides any more exposure (i.e. it is just an encoding choice).  Anybody can form a malicious request (malicious "self" link) - it is still an origin server responsibility to "do the right thing".

Best regards

Paul



On 27 Oct 2012, at 14:15, mca wrote:

> Paul:
> 
> <snip>
> My question is really regarding whether use of the 'Referer' header is a sensible way to identify the URI of the representation that initiated the request.  Additionally, whilst I note some security concerns in RFC 2616, I see no reference to 'Referer' being restricted to any "last page" notion.  Whilst the "referer as last-page" scenario may an artefact of some web usage patterns, I don't think HTTP constrains it in this way.
> </snip>
> 
> I recommend you do not implement your server such that is has a dependency on the Refer header when processing a request. Consider the possibility that someone might bookmark a link and then start a new session w/ that link (no refer). Also consider cases where the client application (user-agent) does not provide a refer header.
> 
> Finally consider the case where someone discovers your use of refer in this way and uses that as a way to craft intentionally invalid requests to run against your server.
> 
> 
> 
> mca
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mikeamundsen