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

add support for 100-continue in HTTP::Server::Response #6912

Merged
merged 1 commit into from
Nov 9, 2018

Conversation

repomaa
Copy link
Contributor

@repomaa repomaa commented Oct 6, 2018

No description provided.

@repomaa repomaa force-pushed the 100-continue branch 3 times, most recently from 23add65 to 76dc76c Compare October 6, 2018 12:09
@straight-shoota
Copy link
Member

Go's webserver implementation doesn't provide a means to send 100 Continue explicitly, but it automatically sends the continue header when Expect: 100-continue is present as soon as the handler reads from the IO.
See https://golang.org/pkg/net/http/#ResponseWriter

Copying this might even be more useful since it just works with any handler and doesn't require any custom logic.

@repomaa
Copy link
Contributor Author

repomaa commented Oct 9, 2018

@straight-shoota That is perfect!

@repomaa repomaa force-pushed the 100-continue branch 3 times, most recently from 904b7b4 to e453c1a Compare October 9, 2018 17:33
src/http/common.cr Show resolved Hide resolved
src/http/common.cr Outdated Show resolved Hide resolved
@straight-shoota
Copy link
Member

I noticed there is an issue when the handler doesn't read from the IO and 100 Continue status should not be sent. A spec for this case is missing. But Content#close calls skip_to_end which read the entire IO and thus sent 100 Continue nonetheless. I suppose #close just needs to set @expects_continue = false before calling skip_to_end.

@straight-shoota
Copy link
Member

Actually, I'm not entirely sure why skip_to_end even is there... It seems to be the only reason for the Content type in the first place.

But I can't see how that is actually useful, and at least, it is confusing to the user. It doesn't just close the IO in it's current state but completely consumes it until the sender is done (maybe a happy curl -T /dev/urandom example.com? 😆 ).
I mean you don't have to call it, just exiting the handler will close the socket without consuming everything.
I'm just wondering what's the use case and if there is a better solution?

@repomaa
Copy link
Contributor Author

repomaa commented Oct 9, 2018

@straight-shoota i agree. this is weird indeed. But I think it should be a seperate issue.

skip_to_end
super
end

def expects_continue=(value : Bool)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps cleaner: property? expects_continue : Bool

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

skip_to_end
super
end

protected def ensure_send_continue
return unless @expects_continue && !@continue_sent
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return unless @expects_continue
return if @continue_sent

address = server.bind_unused_port
spawn { server.listen }

Fiber.yield
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please adjust this according to #6953

@RX14
Copy link
Contributor

RX14 commented Oct 24, 2018

@jreinert needs a format

@repomaa
Copy link
Contributor Author

repomaa commented Oct 24, 2018

@jreinert needs a format

@RX14 done

Copy link
Contributor

@RX14 RX14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one last thing.

@io.peek
end

def skip(bytes_count)
enensure_send_continue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooops

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh jezzus.. i should sleep more. xD

@repomaa repomaa force-pushed the 100-continue branch 3 times, most recently from 4b55742 to 670224d Compare October 28, 2018 12:38
@io.peek
end

def skip(bytes_count)
enensure_send_continue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One en too much.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... i don't... even..

Copy link
Contributor

@Sija Sija Oct 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relax, that happens, especially when there's lack of sleep involved :) I'd just advise "proofreading" your PRs before submitting ;)

@RX14 RX14 requested a review from bcardiff November 7, 2018 16:10
@RX14 RX14 merged commit 735b0be into crystal-lang:master Nov 9, 2018
@RX14 RX14 added this to the 0.27.1 milestone Nov 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants