Ticket #532 (closed design: incorporated)
IESG ballot on draft-ietf-httpbis-p2-semantics-25
|Reported by:||firstname.lastname@example.org||Owned by:||email@example.com|
|Component:||p2-semantics||Severity:||In IESG Evaluation|
Description (last modified by firstname.lastname@example.org) (diff)
Thank you for doing this important work.
Before recommending approval, I would like to briefly discuss with the other ADs on the call about the topic of mentioning injection attacks (in general) in the security considerations section, maybe Section 9.3.
- note that 9.3 is about URIs; injection attacks could happen based on any kind of content, such as header field values and payload; I really don't think this merits special text
2: Even after reading sections 4 & 5, I find the last paragraph of this section almost incomprehensible. Especially given that it's got a normative protocol instruction in it (SHOULD NOT), I think it could use a rewrite.
- Fixed in 
a representation in the payload of a POST request (Section 4.3.3) represents an anonymous resource for providing data to be processed, such as the information that a user entered within an HTML form.
"anonymous resource"? I don't know what that means.
- A resource for which no URI has been supplied or implied by the message. The existing wording is pedantic and distracts from the central point about providing information to be processed by the target resource, so I have removed the use of anonymous resource.
5: Why are you listing (and not providing semantics) for things that are not in this document?
Cache-Control Host Pragma Range TE Age Expires Warning All Conditionals All Authentication
- Because they are in this specification (the document set), which makes them appropriate to cross-reference. The sections are to explain the various kinds of header fields, so providing the examples by reference is instructive to implementers and, IMO, makes the semantics easier to comprehend. It also makes it easier for people familiar with the single-document RFC2616 to find out which part contains the updated definition.
5.3.1: Do you really want to allow a weight of "0." or "1." with no trailing digits? Instead maybe:
qvalue = ( "0" [ "." 1*3DIGIT ] ) / ( "1" [ "." 1*3("0") ] )
- IIRC, yes. There was some argument about that back in 1994-95 and it was decided that allowing the weird syntax is easier than specifying any other interpretation for such a received field value. Implementations at the time actually parsed it as a floating point, so it was not treated as an error in practice. In any case, your suggested change would create an incompatibility with valid RFC2616 messages, which is something we have been strictly avoiding.
5.3.2: Completely bored ABNF dorking:
media-range = ( "*/*" / ( type "/" ( subtype / "*") ) ) *( OWS ";" OWS parameter )
- Equivalent, but I think the existing one is far more readable.
126.96.36.199: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that.
- Fixed by additional comment, see 
In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements is useful and the specification is ultimately there, so OK.
I agree with Stephen's comment that it would be useful to include Origin here in the list of "request context" headers.
Section 5.1.1 defines an entirely new, secondary handshake using a header field. I realize this might be necessary for backward compatibility, but it seems so wrong.
- Yes, it's somewhat problematic. We discussed Expect at some length in the WG, and although some people (including myself) were inclined to deprecate it, we didn't reach consensus to do so. However, we did modify the documentation to make it reflect how it's implemented better.
In Section 5.3.5, "A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field." This seems unnecessary, and unrealistic. For example, on my Mac, Safari sends "Accept-Language: en-us", but as far as I can tell, there is no way to change the value.
- Safari indeed does not allow setting the language, but the OS does. Clarified in 
Okay you're on a role wrt well written. Kudos again!
0) s8.3.1: Should a consideration be whether the new header discloses privacy related-data?
- see #546
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored.
- see #537
0) Abstract: Maybe would add stateless in front of protocol in the description.
- see #538
1) s4.1: Same comment as on p1 about 'ought to' register methods with IANA.
2) s4.3.3/4/5: What Stephen said about authorization. I'm surprised that there's nothing about just accepting things without knowing whence they came.
3) s4.3.7/8: Is it allowed for an HTTP server to just not respond to a OPTIONS/TRACE method? I.e., I'd rather not tell you what I support - kind of like not replying to ping messages? Or is a 501 response always returned.
- You can either close the socket or send a syntactically valid response, in which case status code 501 would be a good choice.
4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF
- The text augments the ABNF; I'd rather not attempt to make it consistent throughout.
5) s5.5.3: So what happens if this isn't followed:
a sender MUST NOT generate advertising or other non-essential information within the product identifier.
- You leak out information that's not needed for the protocol operation.
6) s6.1: Is it worth mentioning that the reason-phrase can also be not sent? I think that's elsewhere but it might be worth mentioning again.
7) s6.4.6: What does a client do if it gets one of these in an HTTP 1.1 response?
- The default 3xx behavior.
8) s4.2.1/s8: "safe" was probably not the greatest of choices - readonly would have been better. But, I guess this is water under the bridge at this point.
- "safe" implies that the client didn't request any state change; however, the server may perform server state changes anyway (such as increasing counters, logging requests...).
Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are a number of ways in which that could have been done (e.g. just a ref, or changing the IANA registry to point to here and update 6454) but making no mention of it at all seems wrong. Please consider whether it'd be worth including that header field here in some form or other.
- From HTTP's point of view, "Origin" simply is one more header field. We have discussed using the terminology (see #322) but came to the conclusion that we don't need it in these specs.
4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when DELETE is allowed.
- I don't understand why we would special-case DELETE in comparison to other state-changing methods such as POST or PUT
4.3.6 makes no mention of TLS - is CONNECT really used without TLS? Seems odd to not mention (what I think) is the main use-case for this method at all.
- Added in 
5.5.2: CSRF attack could do with a reference and expansion of the acronym
- The acronym is expanded -- if the IESG can provide a reference that is suitable for citation in an RFC we could add that; my personal preference would be not to do this though unless it's indeed an IETF document
The paragraph crossing the page break at the bottom of page 16:
For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI.
It's good that there's an example here, but this creates more questions than it answers: if I do a PUT to a particular URI, for which there are currently multiple representations of the document in different languages, based on a GET that had a specific language representation, is the semantics being specified here that the other language representations go away? That's kind of what it sounds like. This text makes sense for different content encodings like JSON and XML, where the server might be able to generate one from the other, but it's giving me a headache thinking about it in terms of natural language. Am I missing the point here? If so, could this be clarified, or did I just not drink enough coffee this morning?
- See #547
I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1. Am I missing something?
- See #548
comment:26 Changed 10 months ago by email@example.com
- Status changed from new to closed
- Resolution set to incorporated
- Description modified (diff)