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

Provide port information when the HTTP request isn't on the default port #1510

Merged
merged 1 commit into from Jun 8, 2016

Conversation

Projects
None yet
3 participants
@Geod24
Contributor

Geod24 commented Jun 4, 2016

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Jun 6, 2016

Contributor

@s-ludwig : This will create another allocation when the port is provided.
I am not so fan of it (this kind of allocation could be avoided), although currently there are many places which use ~ so its in line with current practice.
Since you're doing a major refacto, do you have some plan for those ?

Contributor

Geod24 commented Jun 6, 2016

@s-ludwig : This will create another allocation when the port is provided.
I am not so fan of it (this kind of allocation could be avoided), although currently there are many places which use ~ so its in line with current practice.
Since you're doing a major refacto, do you have some plan for those ?

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Jun 6, 2016

Contributor

Maybe lazy loading these headers only when the user calls req.headers, because otherwise I don't see how it's necessary to preload the container when you can get away with writing them to the stream directly when time comes.

Contributor

etcimon commented Jun 6, 2016

Maybe lazy loading these headers only when the user calls req.headers, because otherwise I don't see how it's necessary to preload the container when you can get away with writing them to the stream directly when time comes.

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Jun 8, 2016

Contributor

@s-ludwig : Ping

Contributor

Geod24 commented Jun 8, 2016

@s-ludwig : Ping

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jun 8, 2016

Member

A simple solution for the current architecture would be to allocate the buffer on the stack, within requestHTTP. I'm planning to add an allocation-less lower layer for the HTTP implementation, which would consist of some kind of callback based system that can be used to write headers directly to the wire. This would be the obvious candidate for a revised version.

BTW, what do you think about dlang/dub#866?

Member

s-ludwig commented Jun 8, 2016

A simple solution for the current architecture would be to allocate the buffer on the stack, within requestHTTP. I'm planning to add an allocation-less lower layer for the HTTP implementation, which would consist of some kind of callback based system that can be used to write headers directly to the wire. This would be the obvious candidate for a revised version.

BTW, what do you think about dlang/dub#866?

@s-ludwig s-ludwig merged commit 4fcdbe9 into vibe-d:master Jun 8, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Geod24 Geod24 deleted the Geod24:fix-1507 branch Jun 8, 2016

@Geod24

This comment has been minimized.

Show comment
Hide comment
@Geod24

Geod24 Jun 8, 2016

Contributor

Thanks !

I'm planning to add an allocation-less lower layer for the HTTP implementation, which would consist of some kind of callback based system that can be used to write headers directly to the wire. This would be the obvious candidate for a revised version.

That sounds very promising. Feel free to ping me when you have something ready.

BTW, what do you think about dlang/dub#866?

Sorry for the late answer. Since I'm subscribed to many thing dlang wise, I may miss some of the notifications.

Contributor

Geod24 commented Jun 8, 2016

Thanks !

I'm planning to add an allocation-less lower layer for the HTTP implementation, which would consist of some kind of callback based system that can be used to write headers directly to the wire. This would be the obvious candidate for a revised version.

That sounds very promising. Feel free to ping me when you have something ready.

BTW, what do you think about dlang/dub#866?

Sorry for the late answer. Since I'm subscribed to many thing dlang wise, I may miss some of the notifications.

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