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

Stop parsing headers when switching to unknown protocols #899

Closed
wants to merge 1 commit into from

Conversation

mkauf
Copy link
Contributor

@mkauf mkauf commented Jun 28, 2016

  • unknown protocols probably won't send more headers (e.g. WebSocket)
  • improved comments and moved them to the correct case statements

- unknown protocols probably won't send more headers (e.g. WebSocket)
- improved comments and moved them to the correct case statements
@jay
Copy link
Member

jay commented Jun 28, 2016

Can you explain what you are trying to do here, isn't it correct to continue to read headers on 101? For example consider this server response (cribbed from wikipedia)

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

@bagder
Copy link
Member

bagder commented Jun 28, 2016

Exactly, the new protocol doesn't actually start until after the set of HTTP/1 headers. Explained in RFC 7230 section 6.7.

But exactly how libcurl should behave in the case of a protocol upgrade to a protocol libcurl doesn't understand has never been defined and documented clearly.

@mkauf
Copy link
Contributor Author

mkauf commented Jun 28, 2016

The code that I have changed gets executed after an empty header line (= end of headers) has been read. It's inside the "if" starting at https://github.com/mkauf/curl/blob/c8a077a2ecc12a7b601a00b3531b79c106b4e49e/lib/http.c#L3022

So the k->header flag controls whether curl expects another set of headers.

But exactly how libcurl should behave in the case of a protocol upgrade to a protocol libcurl doesn't understand has never been defined and documented clearly.

That's right... but probably this protocol does not use HTTP headers (e.g. WebSocket)

@bagder bagder closed this in 7bda07b Aug 25, 2016
@mkauf mkauf deleted the 101_upgrade_headers branch August 29, 2016 12:16
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants