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

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




On Sat, Oct 27, 2012 at 8:53 AM, Paul Moore <[email protected]>wrote:

>
>
> Markus,
>
> Thanks for the response.
>
> With regard to your 'URI per representation' dilemma, this is (as you
> suggest) a separate problem.
>
> From my perspective, by declaring '.../1.json' and '.../1.xml' two
> separate resources have been defined.  There is no *need* to define a URI
> per representation in this manner, as we have 'Content-Type' and 'Accept'
> headers to deal with that.  The resource is simply '.../1' (or whatever)
> and it *may* have multiple representations (one per media type).
>  Irrespective, if a system (designer) chooses to make two (or more) URIs
> available for the same resource, then they are obliged to manage the
> 'mapping' of multiple URIs back to the (canonical) resource.  Returning to
> your example the 'self link' for '.../1.json' should be to '.../1.json' -
> it's a server responsibility to understand that '.../1.json' maps to
> resource '1'.  This is not an interface, but an implementation concern.
>
> 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.
>
> Best regards
>
> Paul
>
> On 26 Oct 2012, at 18:50, Markus Lanthaler wrote:
>
> Paul,
>
> on the Web resources  are identified by URIs, so that leaves us with your
> options 2 and 3. I don’t really see the problems you outline there but a
> different one. What if a system assigns multiple URLs to access the same
> resource but different representations thereof? For instance
> example.com/persons/1.json and example.com/persons/1.xml? Both return
> representations of the same resource and both would likely contain just
> those URLs in the self-link. So the right link relation to use would be
> canonical [1] and not self. That link can then either be embedded directly
> embedded into the representations or served as an HTTP link header [2].
> Using the referrer won't work as that's the page that a user agent visited
> last which might has nothing to do with that resource it is POSTing.
>
> Hope this helps,
> Markus
>
>
> [1] http://tools.ietf.org/html/rfc6596
> [2] http://tools.ietf.org/html/rfc5988
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
> 
>