mnot
commented
10 years ago - julian.reschke@gmx.de changed milestone from
unassignedto26 - julian.reschke@gmx.de changed severity from
In IETF LCtoIn IESG Evaluation
Closed mnot closed 3 years ago
mnot
commented
10 years ago unassigned to 26In IETF LC to In IESG Evaluationmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Major issues:
none
Minor issues:
Part 1 of:
**draft-ietf-httpbis-p1-messaging (82 pages)
draft-ietf-httpbis-p2-semantics (98 pages)
*draft-ietf-httpbis-p4-conditional (27 pages)
draft-ietf-httpbis-p5-range (24 pages)
*draft-ietf-httpbis-p6-cache (41 pages)
draft-ietf-httpbis-p7-auth (18 pages)
draft-ietf-httpbis-method-registrations (7 pages)
draft-ietf-httpbis-authscheme-registrations (5 pages)
** this review
- also reviewed my me (some of comments/suggestions below may apply to all reviews)
-General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs.
It is hard to follow and the protocol is not complex enough to justify these lengthy documents.
I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs.
RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.-General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
-[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would
help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.
-
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"
If the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message-
forwarding intermediaries.
"
-[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".
-[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations,
resource owners, and protocol element registrations when they apply
beyond the scope of a single communication.
"
-[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"
HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies.
"
-[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least
one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"
A client MAY send a lower request version if it is known that the
server incorrectly implements the HTTP specification, but only after
the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., Server) that
the server improperly handles higher request versions.
"
-[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client
address the problem if in reality it was not related to the version of HTTP?
"
A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.
"
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"
A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
"
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port
80 is assumed (the default reserved port for WWW services).
"
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"
If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [Part2], then
that response is considered an authoritative answer to the client's
request.
"
-[Page 21], Should it be section 5.3?
"
Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), ...
"
-[Page 21], just verifying is it three or tree?
"
..., since no whitespace is allowed in the three components.
"
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"
A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients).
"
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"
Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same server.
"
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
Best Regards,
Meral
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Major issues:
none
Minor issues:
Part 1 of:
**draft-ietf-httpbis-p1-messaging (82 pages)
draft-ietf-httpbis-p2-semantics (98 pages)
*draft-ietf-httpbis-p4-conditional (27 pages)
draft-ietf-httpbis-p5-range (24 pages)
*draft-ietf-httpbis-p6-cache (41 pages)
draft-ietf-httpbis-p7-auth (18 pages)
draft-ietf-httpbis-method-registrations (7 pages)
draft-ietf-httpbis-authscheme-registrations (5 pages)
** this review
- also reviewed my me (some of comments/suggestions below may apply to all reviews)
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.-General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
-[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would
help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.
-
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"
If the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message-
forwarding intermediaries.
"
-[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".
-[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations,
resource owners, and protocol element registrations when they apply
beyond the scope of a single communication.
"
-[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"
HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies.
"
-[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least
one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"
A client MAY send a lower request version if it is known that the
server incorrectly implements the HTTP specification, but only after
the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., Server) that
the server improperly handles higher request versions.
"
-[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client
address the problem if in reality it was not related to the version of HTTP?
"
A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.
"
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"
A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
"
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port
80 is assumed (the default reserved port for WWW services).
"
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"
If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [Part2], then
that response is considered an authoritative answer to the client's
request.
"
-[Page 21], Should it be section 5.3?
"
Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), ...
"
-[Page 21], just verifying is it three or tree?
"
..., since no whitespace is allowed in the three components.
"
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"
A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients).
"
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"
Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same server.
"
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
Best Regards,
Meral
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Major issues:
none
Minor issues:
Part 1 of:
**draft-ietf-httpbis-p1-messaging (82 pages)
draft-ietf-httpbis-p2-semantics (98 pages)
*draft-ietf-httpbis-p4-conditional (27 pages)
draft-ietf-httpbis-p5-range (24 pages)
*draft-ietf-httpbis-p6-cache (41 pages)
draft-ietf-httpbis-p7-auth (18 pages)
draft-ietf-httpbis-method-registrations (7 pages)
draft-ietf-httpbis-authscheme-registrations (5 pages)
** this review
- also reviewed my me (some of comments/suggestions below may apply to all reviews)
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.-General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
-[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would
help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.
-
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"
If the communication is considered in isolation, then successful actions
ought to be reflected in corresponding changes to the observable
interface provided by servers. However, since multiple clients might
act in parallel and perhaps at cross-purposes, we cannot require that
such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message-
forwarding intermediaries.
"
-[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".
-[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations,
resource owners, and protocol element registrations when they apply
beyond the scope of a single communication.
"
-[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"
HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies.
"
-[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least
one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"
A client MAY send a lower request version if it is known that the
server incorrectly implements the HTTP specification, but only after
the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., Server) that
the server improperly handles higher request versions.
"
-[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client
address the problem if in reality it was not related to the version of HTTP?
"
A server can send a 505
(HTTP Version Not Supported) response if it wishes, for any reason,
to refuse service of the client's major protocol version.
"
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"
A recipient can assume that a
message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any
implementation of the same major version.
"
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port
80 is assumed (the default reserved port for WWW services).
"
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"
If the server responds to that request with a non-interim
HTTP response message, as described in Section 6 of [Part2], then
that response is considered an authoritative answer to the client's
request.
"
-[Page 21], Should it be section 5.3?
"
Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), ...
"
-[Page 21], just verifying is it three or tree?
"
..., since no whitespace is allowed in the three components.
"
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"
A proxy server MUST NOT maintain a persistent connection with an
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients).
"
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"
Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same server.
"
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
Best Regards,
Meral
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
mnot
commented
10 years ago Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
design to editorialmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Summary:
This draft is almost ready to be published as Proposed Standard but I have some comments.
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
mnot
commented
10 years ago @mnot commented:
"same proxy server" clarification seems OK to me.
mnot
commented
10 years ago julian.reschke@gmx.de commented:
From 2506:
tiny clarification (see #523)
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.
Nits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.htmlNits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
mnot
commented
10 years ago @mnot commented:
"Constructive comment" - without concrete proposals, I suggest we close as is.
mnot
commented
10 years ago Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.htmlNits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
to:
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
-Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. -Most people use www on a daily basis, some of the concepts could be better explained with every day experienced examples rather than abstract explanation.
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.
It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.htmlNits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?
"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."
Not sure if "occasionally other common port traffic" means port 443?
If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:
"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.
(Note that 2 paragraphs below give examples for the server case.)
"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?
"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY..."
"A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".
suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.
(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?
"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)
Also the term "authoritative" is introduced and should be defined in this context.- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1902.html
"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], Should it be section 5.3?
"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 21], just verifying is it three or tree?
"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea.
"A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html
-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server"
"Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506
- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?
(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.html
wontfixnew to closed
Document: draft-ietf-httpbis-p1-messaging-25
Reviewer: Meral Shirazipour
Review Date: 2013-11-18/2013-12-02
IETF LC End Date: End of November (special deadline)
IESG Telechat date: 2013-12-19
Minor issues:
~~ -General comment 1, I am not very keen with the idea of splitting the http standard in so many RFCs. It is hard to follow and the protocol is not complex enough to justify these lengthy documents. I would have rather see 1 concise standard RFC and few Extension RFCs, Informational or BCP RFCs. RFC2616 was ~176 pages, looking at Appendix B of the draft for changes since RFC2616, makes me wonder why so much extra text was required (~300 pages).~~ see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1668.html
Constructive comment:
General comment 2, throughout the text there is mention of security risks yet this is not a complete list for security issues in http.It would be beneficial to also have a separate document for all security risks to be considered by server and client implementors.- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.htmlNits/editorial comments:
[Page 5] in the intro, right after it says "This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616....", it would help to add a reference to Appendix B and mention this is where the differences with RFC2616 is listed.see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 5,6], Section 1, this statement is not clear. Are we talking about one HTTP transaction changing info on the server/data base?"If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries."- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 11], Section 2.3, "Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)."Not sure if "occasionally other common port traffic" means port 443?If not, for sake of completeness, we could say : "redirects outgoing TCP ports 80 and 443 packets".- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 12], Section 2.5 not clear what is meant by (social) requirements. An example may clarify:"Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 13], not a comment for this draft but in general, has the WG considered a BCP for general error handling, in line with the example given after this sentence:"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 15], if the statement below is a well-known and often happening scenario it would help to give at least one example of how a client can deduce that by going to a lower version of HTTP the problem(?) will be fixed.(Note that 2 paragraphs below give examples for the server case.)"A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html[Page 15],can the server send this error message to refuse service based on e.g. connection identification or other reasons? Then how can the client address the problem if in reality it was not related to the version of HTTP?"A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 16], would it be ok to use MAY? If so it would be clearer to use MAY. : "A recipient MAY...""A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 17], Section 2.7.1 first line: "...for the purpose of minting identifiers".suggestion: if another word than "minting" (e.g. generating, creating), could be used it would be easier to read that section.(also used in section 2.7.2)- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 17], "port 80 is assumed", should it be "SHOULD BE" or "MUST BE" ?"If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved port for WWW services)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 17], "non-interim" , not clear how it can be determines as non-interim (no other message in between? or under a certain peruiod of time?)Also the term "authoritative" is introduced and should be defined in this context.- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1902.html"If the server responds to that request with a non-interim HTTP response message, as described in Section 6 of [Part2], then that response is considered an authoritative answer to the client's request."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 21], Should it be section 5.3?"Recipients typically parse the request-line into its component parts by splitting on whitespace (see Section 3.5), ..."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 21], just verifying is it three or tree?"..., since no whitespace is allowed in the three components."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 52], refers to an obsoleted RFC. Maybe repeating the explanation in this draft would be a better idea."A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients)."- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1691.html-[Page 54], suggestion for clarity: "through the same server"--->"through the same proxy server""Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server."- 2506- [Page 65], Security section, is it exhaustive? Would it be better to have a separate draft to discuss all security issues related to HTTP?(also referring to comments from Kathleen Moriarty on other parts of this bis) [See comment 2 in "minor issues" section above]- http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1663.htmlReported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/523