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

HEAD request must not look for a body #114

Open
singpolyma opened this issue Aug 19, 2018 · 1 comment
Open

HEAD request must not look for a body #114

singpolyma opened this issue Aug 19, 2018 · 1 comment
Labels
bug

Comments

@singpolyma
Copy link
Contributor

A HEAD request may contain a Content-Length with a number that would be the size of a GET response, but no actual body to read. It may also contain no such header, but not close the connection when done (web.archive.org does this, for example).

In general, when issuing a request of type HEAD the client should not even try to read a body and should just return an empty InputStream to the handler. Currently the client often hangs when handling such a request.

I'm trying to work around this locally, but since none of the internal modules are exported it's very hard to do, even by copying a lot of the internal code out into my application since I don't have access to data constructors I cannot reimplement receiveResponse for example.
@istathar
Copy link
Member

Well that's a bug. Duplicate #102.

This could be easily fixed if receiveResponse knew what the Request was, but (ages ago) I ripped that out and they're independent now, ie it and sendRequest don't [at Haskell level] share state. To fix this I need to undo that (incidentally, this problem would be a cinch given the obvious way to implement framing in HTTP2, so I'm hoping that when I get around to re-plumbing the library for that this case will get fixed, too).

Hm.

AfC

@istathar istathar added the bug label Aug 19, 2018
singpolyma added a commit to singpolyma/http-streams that referenced this issue Aug 21, 2018
@singpolyma
receivedResponseUnsafe that does not consume body
a233f32 
This works when you know there is no body, no matter what the headers
say (HEAD requests, aesiniath#114)

This also works when the handler consumes whatever part of the body you
actually want to use, and then you close the connection afterwards (no
reusing for pipelining!)  Sometimes this is a lot faster than using
pipelining if you can, for example, skip a many GB download (aesiniath#113)
@singpolyma singpolyma mentioned this issue Aug 21, 2018
Merged
singpolyma added a commit to singpolyma/http-streams that referenced this issue Aug 23, 2018
@singpolyma
unsafeReceiveResponse that does not consume body
3b6d7b6 
This works when you know there is no body, no matter what the headers
say (HEAD requests, aesiniath#114)

This also works when the handler consumes whatever part of the body you
actually want to use, and then you close the connection afterwards (no
reusing for pipelining!)  Sometimes this is a lot faster than using
pipelining if you can, for example, skip a many GB download (aesiniath#113)
singpolyma added a commit to singpolyma/http-streams that referenced this issue Aug 23, 2018
@singpolyma
unsafeReceiveResponse that does not consume body
5d48210 
This works when you know there is no body, no matter what the headers
say (HEAD requests, aesiniath#114)

This also works when the handler consumes whatever part of the body you
actually want to use, and then you close the connection afterwards (no
reusing for pipelining!)  Sometimes this is a lot faster than using
pipelining if you can, for example, skip a many GB download (aesiniath#113)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@singpolyma @istathar