Loading ...
Sorry, an error occurred while loading the content.

Fwd: [rest-discuss] How to identify existing resource in a POST(a) request

Expand Messages
  • mike amundsen
    Paul: 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
    Message 1 of 1 , Oct 27, 2012
    • 0 Attachment
      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



      On Sat, Oct 27, 2012 at 8:53 AM, Paul Moore <paul.k.moore@...> 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





    Your message has been successfully submitted and would be delivered to recipients shortly.