Opened 11 years ago

Closed 9 years ago

Last modified 7 years ago

#136 closed editorial (fixed)

confusing req. language for Content-Location

Reported by: julian.reschke@… Owned by:
Priority: urgent Milestone: 11
Component: p3-payload Severity: Active WG Document
Keywords: Cc:

Description

RFC 2616 says:

The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned. --

<http://tools.ietf.org/html/rfc2616#section-14.14>

Comments:

  • the first "MAY" seems to be useless and actually distracting ("may be

used", "can be used" or "is used" would be just fine)

  • "...when that entity is accessible from a location separate from the

requested resource's URI" -- can this be simplified to "when that entity is accessible from a location separate from the request-URI"? Or am I missing something here?

  • then it goes on saying server "SHOULD" return the header, but then

"SHOULD return especially" in some special cases -- but there was already an unconditional SHOULD without that condition.

Part of this confusion seems to be the result of trying to BCP14fy what RFC2068 said (which had the first "SHOULD" in lower case).

So, looking at RFC 2068:

The Content-Location entity-header field may be used to supply the resource location for the entity enclosed in the message. In the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server should provide a Content-Location for the particular variant which is returned. In addition, a server SHOULD provide a Content-Location for the resource corresponding to the response entity. --

<http://tools.ietf.org/html/rfc2068#section-14.15>

This looks a bit better, except for the last sentence:

"In addition, a server SHOULD provide a Content-Location for the resource corresponding to the response entity."

...which I frankly do not understand -- what does it say what hasn't been said before?

So if I had to rewrite this I would make it just:

The Content-Location entity-header field may be used to supply the resource location for the entity enclosed in the message. In the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

(BCP14fying the should, dropping the last sentence)

Attachments (1)

136.diff (1.3 KB) - added by julian.reschke@… 10 years ago.
Proposed patch for part 3.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 10 years ago by mnot@…

  • Priority set to urgent

Changed 10 years ago by julian.reschke@…

Proposed patch for part 3.

comment:2 Changed 9 years ago by fielding@…

From [856]:

Addresses #69: Clarify "Requested Variant" Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with payload and variant with representation. Cleaned up description of 204 status code (related to ticket #22) Rewrote section on Content-Location and refer to def in RFC2557.

Addresses #110: Clarify rules for determining what entities a response carries

Detail the rules for Content-Location and remove the cross-ref.

Addresses #167: Content-Location on 304 responses

Removed sentence in C-Loc that refers to using C-Loc to select a

variant from cache (an already removed "feature")

Addresses #136: confusing req. language for Content-Location

Removed the confusing paragraph because HTTP does not know anything about variants behind the resource interface and thus cannot make this an interop requirement. In any case, it only existed to support the already removed cache feature that nobody implemented.

Addresses #80: Content-Location isn't special

Clarifies that C-Loc is representation metadata and what (not) to do with it if received on a request.

comment:3 Changed 9 years ago by fielding@…

  • Milestone changed from unassigned to 11
  • Resolution set to incorporated
  • Status changed from new to closed

Removed the confusing paragraph because HTTP does not know anything about variants behind the resource interface and thus cannot make this an interop requirement. In any case, it only existed to support the already removed cache feature that nobody implemented.

comment:4 Changed 9 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:5 Changed 9 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:6 Changed 7 years ago by mnot@…

  • Severity changed from Candidate WG Document to Active WG Document
Note: See TracTickets for help on using tickets.