You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 6, 2022. It is now read-only.
The presence of a message body in a request is signaled by a
Content-Length or Transfer-Encoding header field. Request message
framing is independent of method semantics, even if the method does
not define any use for a message body.
i.e. A request that says Content-Length: 10 has a 10-byte body irrespective of the method being CONNECT.
The CONNECT scemantics are defined here: RFC 7231, 4.3.6. It talks about the client ignoring *responses( with Content-Length in, however, that is not relevant to this test request test case.
A server MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to CONNECT. A client MUST
ignore any Content-Length or Transfer-Encoding header fields received
in a successful response to CONNECT.
RFC 7231, 4.3.6 goes on to say that a payload on a CONNECT request has no defined meaning, but it does not disallow it:
A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing
implementations to reject the request.
Activity
samoconnor commentedon Jan 11, 2018
Related to #401 ?
[-]CONNECT_WITH_BODY_REQUEST maybe worng[/-][+]Test "CONNECT_WITH_BODY_REQUEST" maybe worng[/+]Messages.jl
Remove redundant header interpretation from Parser.
WIP: Factorisation of implementation into modules and layers (#135)