mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Jari Arkko
Comment (2013-12-19)
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.
Pete Resnick
Comment (2013-12-18)
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.
3.3
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.
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
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") ] )5.3.2: Completely bored ABNF dorking:
media-range = ( "*/*" / ( type "/" ( subtype / "*") ) ) *( OWS ";" OWS parameter )7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that.
Richard Barnes
Comment (2013-12-18)
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.
COMMENT 1: 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.
COMMENT 2: 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.
Sean Turner
Discuss (2013-12-19)
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?
Comment (2013-12-19)
*) 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.
0) Abstract: Maybe would add stateless in front of protocol in the description.
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.
4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF
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.
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?
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.
Stephen Farrell
Comment (2013-12-18)
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.
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.
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.
5.5.2: CSRF attack could do with a reference and expansion of the acronym
Ted Lemon
Comment (2013-12-19)
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?
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?
to:
Jari Arkko
Comment (2013-12-19)
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.
Pete Resnick
Comment (2013-12-18)
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.
3.3
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.
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
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") ] )5.3.2: Completely bored ABNF dorking:
media-range = ( "*/*" / ( type "/" ( subtype / "*") ) ) *( OWS ";" OWS parameter )7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that.
Richard Barnes
Comment (2013-12-18)
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.
COMMENT 1: 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.
COMMENT 2: 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.
Sean Turner
Discuss (2013-12-19)
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?
Comment (2013-12-19)
*) 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.
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.
4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF
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.
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?
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.
Stephen Farrell
Comment (2013-12-18)
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.
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.
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.
5.5.2: CSRF attack could do with a reference and expansion of the acronym
Ted Lemon
Comment (2013-12-19)
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?
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?
Jari Arkko
Comment (2013-12-19)
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.
Pete Resnick
Comment (2013-12-18)
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.
3.3
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.
5: Why are you listing (and not providing semantics) for things that are not in this document?
5.3.1: Do you really want to allow a weight of "0." or "1." with no trailing digits? Instead maybe:
5.3.2: Completely bored ABNF dorking:
7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that.
Richard Barnes
Comment (2013-12-18)
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.
COMMENT 1:
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.
COMMENT 2:
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.
Sean Turner
Discuss (2013-12-19)
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?
Comment (2013-12-19)
*) 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.
0) Abstract: Maybe would add stateless in front of protocol in the description.
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.
4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF
5) s5.5.3: So what happens if this isn't followed:
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?
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...).'''
Stephen Farrell
Comment (2013-12-18)
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.
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.
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.
5.5.2: CSRF attack could do with a reference and expansion of the acronym
Ted Lemon
Comment (2013-12-19)
The paragraph crossing the page break at the bottom of page 16:
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?
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?
Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/532