Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Artart last call review of draft-ietf-httpbis-messaging-18 #966

Closed
7 tasks done
reschke opened this issue Sep 4, 2021 · 1 comment
Closed
7 tasks done

Artart last call review of draft-ietf-httpbis-messaging-18 #966

reschke opened this issue Sep 4, 2021 · 1 comment

Comments

@reschke
Copy link
Contributor

reschke commented Sep 4, 2021

Reviewer: Marco Tiloca
Review result: Ready with Nits

Thanks for this document! I have found it very well written and I believe it's
basically ready.

Please, see below some minor comments and nits.

Best,
/Marco

  • [Section 1.2]
  • As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP].

Editors: 26a3a5e

  • [Section 3]
  • "HTTP does not place a predefined limit on the length of a request-line, as
    described in Section 2 of [HTTP]"

    This can better point to Section 2.3 of [HTTP].

Editors: 17d1958

  • [Section 3.2]
  • "A client MUST send a Host header field in all HTTP/1.1 request messages."

    This sentence can be expanded to point to Section 7.2 of [HTTP].

  • "... excluding any userinfo subcomponent and its "@" delimiter ..."

    This should point to Section 4.2.4 of [HTTP].

Editors: dbee984

  • [Section 3.3]
  • "Alternatively, it might be better to redirect the request to a safe resource
    that explains how to obtain a new client."

    Is "client" actually the intended word here? Or is it about using
    redirection to explain the client how to obtain something else (e.g. a
    proper authority component for a follow-up request) ?

Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995.

  • [Section 7.1.2]
  • I believe it's better for the reader if the last paragraph is split into 2 or
    3 sentences

Editors: #969

  • [Section 9.8]
  • "When encountering an incomplete close, a client SHOULD treat as completed
    all requests for which it has received ..."

    Shouldn't this be about received responses? Or does it refer to the
    completion of the exchanges started by the mentioned requests?

Editors: yes, it's about the completion of the exchanges.

  • [Appendix A]
  • The first paragraph can better point to Section 5.6.1 of [HTTP].

Editors: 1bea457

  • The reference for "absolute-path" should be Section 4.1 of [HTTP].

Editors: 26a3a5e

@reschke
Copy link
Contributor Author

reschke commented Sep 5, 2021

[Section 7.1.2]

I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences

Long indeed. @royfielding - do you want to give that a try?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant