Martin Duke COMMENT on draft-ietf-httpbis-semantics-16

[mnot]

• (7.6.3) Via

"If a port is not provided, a recipient MAY interpret that as meaning it was
received on the default TCP port, if any, for the received-protocol."

So if received-protocol is "3", it's a UDP port.

If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the
scheme isn't included to determine this.

Editors: #881

---

• (7.7) Message Transformations

"A proxy that transforms the content of a 200 (OK) response can inform
downstream recipients that a transformation has been applied by changing the
response status code to 203 (Non-Authoritative Information)"

Why not an normative word, instead of "can"?

Editors: #857 (comment)

---

• (12.5.3) Is it correct that "identity" and having no field value for
  Accept-Encoding are synonymous?

Editors: #857 (comment)

---

• "Servers that fail a request due to an unsupported content coding ought to
  respond with a 415 (Unsupported Media Type) status"

Why not s/ought to/SHOULD ?

Editors: #857 (comment)

---

• (14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not
  intermediaries?

Editors: #882

---

• (15.3.7) "A sender that generates a 206 response with an If-Range header
  field"... (13.1.5) leads me to believe that only clients can send If-Range. So
  how can there be a response with If-Range?

Editors: #883

---

• (15.3.7.2) The last instance of THIS_STRING_SEPARATES has a trailing '--'. If
  this is intentional, it ought to be explained.

Editors: #857 (comment)

---

• (16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they
  SHOULD begin with "an alphanumeric character". More broadly, the "Field name:"
  description in (16.3.1) should probably refer to (16.3.2.1) unless I'm
  misunderstanding the scope of these sections.

Editors: #890

---

• (17.13) s/TCP behavior/TCP or QUIC behavior

Editors: #884

---

• (B) It would be good to mention here that accept-ext has been removed in
  (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this
  spec.

Editors: see #886 and #885

[mnot]

Why not an normative word, instead of "can"?

Because it isn't required, nor is it widely implemented (if at all). We try not to make requirements that we know won't be honoured.

[mnot]

(14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries?

Because the header is information about the capabilities of the origin server, not other members of the request chain. Intermediaries can change (e.g., with proxy configuration). Note that a gateway (e.g., a CDN) is effectively acting as an origin server, so it can do this.

The language in this section needs to be tweaked, however; there are a few instances of 'server' that should be 'origin server'.

[mnot]

(15.3.7) "A sender that generates a 206 response with an If-Range header
field"... (13.1.5) leads me to believe that only clients can send If-Range. So
how can there be a response with If-Range?

It looks like the phrase 'to a request' was dropped somewhere between 7233 and now.

[mnot]

(15.3.7.2) The last instance of THIS_STRING_SEPARATES has a trailing '--'. If
this is intentional, it ought to be explained.

This is how multipart works; see RFC2046. I don't think there's value in re-specifying it here.

[mnot]

Is it correct that "identity" and having no field value for Accept-Encoding are synonymous?

As per the spec:

An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.

...

An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in response.

[reschke]

"Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status"

Why not s/ought to/SHOULD ?

Because we avoid making existing servers that predate this spec non-compliant (unless there's a very good reason, such as security)