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

SSL #1

Closed
seanmonstar opened this issue Sep 3, 2014 · 9 comments
Closed

SSL #1

seanmonstar opened this issue Sep 3, 2014 · 9 comments
Labels
A-server Area: server.

Comments

@seanmonstar
Copy link
Member

No description provided.

@seanmonstar seanmonstar added A-client Area: client. A-server Area: server. and removed A-client Area: client. labels Sep 10, 2014
@seanmonstar
Copy link
Member Author

ssl support for the client exists, still lacking server support

@cactorium
Copy link
Contributor

Is it alright if I take a stab at this?

@seanmonstar
Copy link
Member Author

@cactorium I'd be delighted if this showed up as a PR :D

Some notes: I'd imagine adding a pub fn https(ip: IpAddr, port: Port, cert: Path, key: Path) or something similar. The paths to the cert and key can be Options on the Server. The HttpListener would probably need to become an enum similar to HttpStream, and the Https variant accepting those Paths.

@cactorium
Copy link
Contributor

@seanmonstar Awesome :D

I think I did it? #199 I'm still working on figuring out how to test it, but here's something to look at for now

@veeti
Copy link

veeti commented Dec 31, 2014

What's the story for certificate validation in the client?

@cactorium
Copy link
Contributor

https://github.com/hyperium/hyper/blob/master/src/net.rs#L257 It looks like they're verified, peek around there and the openssl docs if you want more details: https://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html

@seanmonstar
Copy link
Member Author

@veeti see http://hyperium.github.io/hyper/hyper/client/struct.Client.html#method.set_ssl_verifier

@veeti
Copy link

veeti commented Dec 31, 2014

Thanks: so (rust-)openssl does verification, but is something required on the hyper side? I see there's no default verifier included and the provided client example accepts everything for me. Is this expected? Should I file a bug for this?

@seanmonstar
Copy link
Member Author

@veeti you can set a verifier function on Client. I guess a default could be similar to Python or nodejs.

Manishearth pushed a commit to Manishearth/hyper that referenced this issue Jan 12, 2015
@jdm
Merge pull request hyperium#1 from glennw/rustc_workaround
bbc38be 
Update servo branch for rust upgrade + rustc workaround for SendStr issue.
ayax79 pushed a commit to ayax79/hyper that referenced this issue Jan 14, 2015
@cactorium
feat(server,net): Add TLS/SSL support serverside
e04edea 
Implements the missing enum cases in Http* and adds a new
method to the default Server implementation to take advantage
of the new TLS support

Closes hyperium#1
@codahale codahale mentioned this issue Mar 31, 2015
Closed
@jnicholls jnicholls mentioned this issue Aug 8, 2015
Closed
@PeterSP PeterSP mentioned this issue Jan 15, 2016
Closed
@jhinrichsen jhinrichsen mentioned this issue Sep 13, 2019
Closed
@ghost ghost mentioned this issue Jul 4, 2021
Closed
@JakkuSakura JakkuSakura mentioned this issue Jul 11, 2021
Closed
@bagder bagder mentioned this issue Oct 22, 2021
Open
@whentze whentze mentioned this issue Nov 6, 2021
Closed
@sfackler sfackler mentioned this issue Jan 1, 2022
Closed
@SpyrosRoum SpyrosRoum mentioned this issue Mar 20, 2022
Open
@RalfJung RalfJung mentioned this issue Mar 27, 2022
Closed
@firstdorsal firstdorsal mentioned this issue Aug 24, 2022
Closed
@bk2204 bk2204 mentioned this issue Sep 23, 2022
Closed
@ghost ghost mentioned this issue Oct 28, 2022
Closed
@flumm flumm mentioned this issue Dec 2, 2022
Closed
This was referenced Dec 8, 2022
Closed
Closed
@billyb2 billyb2 mentioned this issue Mar 14, 2023
Closed
@MorganR MorganR mentioned this issue Mar 28, 2023
Closed
@bim9262 bim9262 mentioned this issue Oct 3, 2023
Closed
@francoposa francoposa mentioned this issue Dec 30, 2023
Closed
@kanpov kanpov mentioned this issue Sep 22, 2024
Closed
@linyihai linyihai mentioned this issue Dec 2, 2024
Closed
dicej added a commit to dicej/hyper that referenced this issue Dec 17, 2024
@dicej
hacky support for 1xx informational responses
0fe9a87 
It's ugly, but here's what I did:

- Add `service::InformationalSender`, a type which wraps a
  `futures_channel::mspc::Sender<Response<()>>`.  This may be added as an
  extension to a `Request` by the Hyper server, and the application and/or
  middleware may use it to send one or more informational responses before
  sending the real one.

- Add code to proto::h1::dispatch and friends to add such an extension to each
  incoming request and then poll the `Receiver` end along with the future
  representing the final response.  If the app never sends any informational
  responses, then everything proceeds as normal.  Otherwise, we send those
  responses as they become available until the final response is ready.

TODO hyperium#1: Also support informatinal responses in the HTTP/2 server.
TODO hyperium#2: Come up with a less hacky API.

Signed-off-by: Joel Dice <[email protected]>
dicej added a commit to dicej/hyper that referenced this issue Dec 18, 2024
@dicej
hacky support for 1xx informational responses
d213cf2 
It's ugly, but here's what I did:

- Add `ext::InformationalSender`, a type which wraps a
  `futures_channel::mspc::Sender<Response<()>>`.  This may be added as an
  extension to an inbound `Request` by the Hyper server, and the application
  and/or middleware may use it to send one or more informational responses
  before sending the real one.

- Add code to proto::h1::dispatch and friends to add such an extension to each
  inbound request and then poll the `Receiver` end along with the future
  representing the final response.  If the app never sends any informational
  responses, then everything proceeds as normal.  Otherwise, we send those
  responses as they become available until the final response is ready.

TODO hyperium#1: Also support informational responses in the HTTP/2 server.
TODO hyperium#2: Come up with a less hacky API?

Signed-off-by: Joel Dice <[email protected]>
dicej added a commit to dicej/hyper that referenced this issue Dec 18, 2024
@dicej
prototype support for 1xx informational responses
dfaccce 
This is a prototype intended to spur discussion about what support for 1xx
informational responses should look like in a Hyper server.  The good news is
that it works great (for HTTP/1 only, so far).  The bad news is it's kind of
ugly.  Here's what I did:

- Add `ext::InformationalSender`, a type which wraps a
  `futures_channel::mspc::Sender<Response<()>>`.  This may be added as an
  extension to an inbound `Request` by the Hyper server, and the application
  and/or middleware may use it to send one or more informational responses
  before sending the real one.

- Add code to `proto::h1::dispatch` and friends to add such an extension to each
  inbound request and then poll the `Receiver` end along with the future
  representing the final response.  If the app never sends any informational
  responses, then everything proceeds as normal.  Otherwise, we send those
  responses as they become available until the final response is ready.

TODO hyperium#1: Also support informational responses in the HTTP/2 server.
TODO hyperium#2: Come up with a less hacky API?
TODO hyperium#3: Add test coverage.

Signed-off-by: Joel Dice <[email protected]>
dicej added a commit to dicej/hyper that referenced this issue Dec 18, 2024
@dicej
prototype support for 1xx informational responses
e06150e 
This is a prototype intended to spur discussion about what support for 1xx
informational responses should look like in a Hyper server.  The good news is
that it works great (for HTTP/1 only, so far).  The bad news is it's kind of
ugly.  Here's what I did:

- Add `ext::InformationalSender`, a type which wraps a
  `futures_channel::mspc::Sender<Response<()>>`.  This may be added as an
  extension to an inbound `Request` by the Hyper server, and the application
  and/or middleware may use it to send one or more informational responses
  before sending the real one.

- Add code to `proto::h1::dispatch` and friends to add such an extension to each
  inbound request and then poll the `Receiver` end along with the future
  representing the final response.  If the app never sends any informational
  responses, then everything proceeds as normal.  Otherwise, we send those
  responses as they become available until the final response is ready.

TODO hyperium#1: Also support informational responses in the HTTP/2 server.
TODO hyperium#2: Come up with a less hacky API?
TODO hyperium#3: Add test coverage.

Signed-off-by: Joel Dice <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-server Area: server.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seanmonstar @veeti @cactorium