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
base: master
from

Conversation

Projects
None yet
3 participants
@mkauf
Contributor

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
Stop parsing headers when switching to unknown protocols
- unknown protocols probably won't send more headers (e.g. WebSocket)
- improved comments and moved them to the correct case statements
@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay Jun 28, 2016

Member

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
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

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Jun 28, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@mkauf

mkauf Jun 28, 2016

Contributor

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)

Contributor

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 mkauf:101_upgrade_headers branch Aug 29, 2016

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