* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #136 (closed editorial: fixed)

Opened 6 years ago

Last modified 2 years ago

confusing req. language for Content-Location

Reported by: julian.reschke@gmx.de Owned by:
Priority: urgent Milestone: 11
Component: p3-payload Severity: Active WG Document
Keywords: Cc:
Origin: http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0259.html

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

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

Change History

comment:1 Changed 5 years ago by mnot@pobox.com

  • Priority set to urgent

Changed 5 years ago by julian.reschke@gmx.de

Proposed patch for part 3.

comment:2 Changed 4 years ago by fielding@gbiv.com

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 4 years ago by fielding@gbiv.com

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

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 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:5 Changed 4 years ago by mnot@pobox.com

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

comment:6 Changed 2 years ago by mnot@pobox.com

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