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.

Sign up for GitHub

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

Jump to bottom

Section 5.4 (Host) in Semantics has normative 1.1 requirements #182

Closed
quasicomputational opened this issue Dec 1, 2018 · 6 comments · Fixed by #412
Closed

Section 5.4 (Host) in Semantics has normative 1.1 requirements #182

quasicomputational opened this issue Dec 1, 2018 · 6 comments · Fixed by #412
Assignees
@mnot
Labels
has-proposal semantics

Comments

@quasicomputational
Copy link

In section 5.4, there are a couple of normative requirements for HTTP/1.1 ("A client MUST send a Host header field in all HTTP/1.1 request messages."; "A client MUST send a Host header field in an HTTP/1.1 request"; "A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request"), and it makes two references to the absolute-form production, which is defined in the Messaging draft (and hence is a dangling reference in Semantics). Those should probably live in Messaging, and the Semantics document should be more general.
@mnot mnot added the semantics label Dec 18, 2018
@reschke
Copy link
Contributor

reschke commented Feb 25, 2019

The references are dangling because the definition of "Host" moved (was in RFC 7230 before).

@royfielding royfielding self-assigned this Feb 2, 2020
This was referenced Mar 19, 2020
Closed
Closed
@mnot
Copy link
Member

mnot commented Jul 2, 2020

E.g.,

A client must send a Host header field in all HTTP/1.1 request messages.

and

A server must respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field

@mnot mnot assigned mnot and unassigned royfielding Jul 2, 2020
@mnot
Copy link
Member

mnot commented Jul 20, 2020

Looking for a place in messaging to move these. What about 3.3 Reconstructing the Target URI?

@mnot mnot mentioned this issue Jul 20, 2020
Merged
@mnot
Copy link
Member

mnot commented Jul 29, 2020

@royfielding @reschke see question above ^^

@reschke
Copy link
Contributor

reschke commented Jul 29, 2020

yes, 3.3 looks ok for that

@mnot
Copy link
Member

mnot commented Aug 3, 2020

The end of 3.2 seemed like a better fit in the end; PTAL.

reschke added a commit that referenced this issue Aug 5, 2020
@reschke
change log (#182)
fcde9f7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mnot mnot

Labels
has-proposal semantics
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Host is 1.1-specific httpwg/http-core
4 participants
@mnot @reschke @royfielding @quasicomputational