support HTTPS #17

Open
hsenag opened this Issue Oct 9, 2011 · 9 comments

Comments

Projects
None yet
5 participants
@hsenag
Member

hsenag commented Oct 9, 2011

No description provided.

@zhensydow

This comment has been minimized.

Show comment Hide comment
@zhensydow

zhensydow Oct 25, 2011

I'm interested in this feature, I want to help but I don't know anything about to implement it. is it possible to help you anyway? did you have a roadmap to implement https? maybe I can help in some steps.

Thanks

I'm interested in this feature, I want to help but I don't know anything about to implement it. is it possible to help you anyway? did you have a roadmap to implement https? maybe I can help in some steps.

Thanks

@hsenag

This comment has been minimized.

Show comment Hide comment
@hsenag

hsenag Oct 25, 2011

Member

No roadmap, I'm afraid. I did have a vague idea of using https://github.com/vincenthz/hs-tls, but nothing more than that.

Member

hsenag commented Oct 25, 2011

No roadmap, I'm afraid. I did have a vague idea of using https://github.com/vincenthz/hs-tls, but nothing more than that.

@hvr

This comment has been minimized.

Show comment Hide comment
@hvr

hvr Dec 23, 2011

Owner

Fwiw, http-enumerator already supports https (which might serve as an TLS API usage example)

Owner

hvr commented Dec 23, 2011

Fwiw, http-enumerator already supports https (which might serve as an TLS API usage example)

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Jul 5, 2012

I vote against, I like to see a strict separation of secure tunnels and the HTTP protocol. This keeps the set of dependencies small, and thus the size of resulting binaries. However, the HTTP package is really in need of some improvement.

I think the main problem is that the HTTP package isn't very aware of tunneling. Well, it was with the now pretty much deprecated Stream interface (which uses Strings but can be extended for tunneling), but not with the HStream interface (which can't be extended for tunneling, but can be extended to support multiple types of buffers). I'll commit a pull request at https://github.com/vincenthz/hs-tls-extra for my implementation of a Stream instance for TLS, which can then be used in conjunction with Network.HTTP.Stream, but I hope the main developers of the HTTP package fix the API to truly support tunneling.

ghost commented Jul 5, 2012

I vote against, I like to see a strict separation of secure tunnels and the HTTP protocol. This keeps the set of dependencies small, and thus the size of resulting binaries. However, the HTTP package is really in need of some improvement.

I think the main problem is that the HTTP package isn't very aware of tunneling. Well, it was with the now pretty much deprecated Stream interface (which uses Strings but can be extended for tunneling), but not with the HStream interface (which can't be extended for tunneling, but can be extended to support multiple types of buffers). I'll commit a pull request at https://github.com/vincenthz/hs-tls-extra for my implementation of a Stream instance for TLS, which can then be used in conjunction with Network.HTTP.Stream, but I hope the main developers of the HTTP package fix the API to truly support tunneling.

@hsenag

This comment has been minimized.

Show comment Hide comment
@hsenag

hsenag Jul 5, 2012

Member

HTTP doesn't have any really active developers, I'm afraid. I'm happy to accept patches (after review/discussion), or to discuss handing over maintainership if someone with more time for the package than me comes along.

Member

hsenag commented Jul 5, 2012

HTTP doesn't have any really active developers, I'm afraid. I'm happy to accept patches (after review/discussion), or to discuss handing over maintainership if someone with more time for the package than me comes along.

@bytbox

This comment has been minimized.

Show comment Hide comment
@bytbox

bytbox Sep 17, 2013

I'm interested in adding HTTPS support; just wanted to check in to make sure that a) nobody's working on it already and b) it's still a desired feature by the package maintainers. Any objections/comments?

bytbox commented Sep 17, 2013

I'm interested in adding HTTPS support; just wanted to check in to make sure that a) nobody's working on it already and b) it's still a desired feature by the package maintainers. Any objections/comments?

@hsenag

This comment has been minimized.

Show comment Hide comment
@hsenag

hsenag Sep 17, 2013

Member

I don't know of anyone working on it and it's definitely desired by me as maintainer!

Member

hsenag commented Sep 17, 2013

I don't know of anyone working on it and it's definitely desired by me as maintainer!

@hsenag

This comment has been minimized.

Show comment Hide comment
@hsenag

hsenag Nov 14, 2013

Member

BTW I should have added that one obstacle to getting HTTPS support merged to the mainline HTTP package will be getting any dependencies (like hs-tls or whatever) into the Haskell Platform.

However, if that proves to be difficult, we could maintain a branch and release a "HTTPS" package from that branch or something along those lines in the meantime.

Member

hsenag commented Nov 14, 2013

BTW I should have added that one obstacle to getting HTTPS support merged to the mainline HTTP package will be getting any dependencies (like hs-tls or whatever) into the Haskell Platform.

However, if that proves to be difficult, we could maintain a branch and release a "HTTPS" package from that branch or something along those lines in the meantime.

@mietek

This comment has been minimized.

Show comment Hide comment
@mietek

mietek Nov 15, 2017

This is still an issue.

mietek commented Nov 15, 2017

This is still an issue.

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