Brought up server using the simple example from front page.
This is when using actix-web = "1.0.8".
$ curl --verbose --http2-prior-knowledge -X GET http://127.0.0.1:8080/test/100/index.html
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x557e924e3580)
> GET /test/100/index.html HTTP/2
> Host: 127.0.0.1:8080
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< content-length: 12
< date: Thu, 12 Mar 2020 19:47:04 GMT
<
* Connection #0 to host 127.0.0.1 left intact
Hello world!
main.rs is a little different
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
fn index() -> impl Responder {
HttpResponse::Ok().body("Hello world!")
}
fn main() -> std::io::Result<()> {
println!("Listening on http://0.0.0.0:8080");
HttpServer::new(|| {
App::new()
.route("/{name}/{id}/index.html", web::get().to(index))
})
.bind("0.0.0.0:8080")?
.run()
}
This is when using actix-web = "2"
$ curl --verbose --http2-prior-knowledge -X GET http://127.0.0.1:8080/test/100/index.html
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5654880f0580)
> GET /test/100/index.html HTTP/2
> Host: 127.0.0.1:8080
> User-Agent: curl/7.58.0
> Accept: */*
>
* http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly.
* Connection #0 to host 127.0.0.1 left intact
curl: (16) Error in the HTTP2 framing layer
I'm trying to upgrade my actix-web to latest release to utilize the new features but blocked here.
$ rustc -V
rustc 1.42.0 (b8cedc004 2020-03-09)
the website docs elude to cleartext support for http2 but see this comment also:
https://github.com/actix/actix-web/issues/753#issuecomment-480091639
@sallyyu0 I'm confused what are you trying to achieve in this Issue. Would you please explain in other words?
@Dowwie I've been using actix as http/2 server without TLS. But it stopped working with 2.0 now. I don't know if this is done intentionally that actix-web 2.0 will no longer support H2C, or it's just somehow got broken. Since I'm planing to upgrade from 1.0.8 to 2.0 now.,
@robjtede It's true that client does not support http/2 without TLS so I used h2 crate (https://docs.rs/h2/0.2.2/h2/) to achieve the client side.
But actix-web::server has been working for me. However, it is private now so I changed to use HttpServer which does not work. Can you change server to public? Also tried HttpServer in 1.0.8 and it also works for http/2 w/o TLS.
error[E0603]: module `server` is private
--> src/main.rs:4:50
|
4 | use actix_web::{web, App, Responder, HttpServer, server};
| ^^^^^^ this module is private
|
note: the module `server` is defined here
--> /home/test/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-2.0.0/src/lib.rs:97:1
|
97 | mod server;
| ^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0603`.
error: could not compile `rust-svr`.
@sallyyu0 apologies, I missed the "client" part of that issue
@sallyyu0 we recently resolved an h2 issue on master that was related to misconfiguration, but this was in the context of awc connections. If we are lucky, the issue you are having will also be configurational. You're going to have to do some research and help. As long as this functionality worked before 2.0, we should be able to fix it.
@dunnock thoughts?
@Dowwie yeah, that was a little bit different though example used a trick for replacing connection, it might be working here too.
@sallyyu0 not sure if following will work, but I don't see why it would not. Can you try to set server with custom TcpListener that you provide? https://docs.rs/actix-web/2.0.0/actix_web/struct.HttpServer.html#method.listen
Also you may look at using H2Service directly: https://docs.rs/actix-http/1.0.1/actix_http/h2/struct.H2Service.html tcp version.
@dunnock How would using TcpListener make any difference? I don't have any additional custom setting for the listener except address as what's done in bind(). Are you saying that I could set scheme somehow? I see that there are two scheme in the file, "http" and 'https', what's for http/2? I remember that setting scheme did not work for client.
@sallyyu0 yeah, bind would work too. So you need to change the way how HttpService initialized using H2Service, like below based on example from actix-http:
use std::{env, io};
use actix_http::http::HeaderValue;
use actix_http::{Error, HttpService, Request, Response};
use actix_server::Server;
async fn handle_request(mut req: Request) -> Result<Response, Error> {
Ok(Response::Ok()
.body(req.uri().to_string()))
}
#[actix_rt::main]
async fn main() -> io::Result<()> {
Server::build()
.bind("echo", "127.0.0.1:8080", || {
HttpService::build().h2(handle_request).tcp()
})?
.run().await
}
@sallyyu0 have you managed to reach a resolution with this help?
@Dowwie Yes, it works. Thank you. But that means I'll have to give up actix-web and involves big change. I'd prefer that it can be fixed in 2.0.0.
@dunnock It works, but it can't support http1 in the meantime. There will be restrictions on application.
I also got hit by this. Any plans to fix it or I should look for alternative solutions? Thanks
Same -- I was exploring using actix-web to front gRPC microservices, and we don't use TLS (intentionally) since we use UDS or localhost non-TLS connections (e.g., with containers). I could switch to TLS, but then I can't really compare performance against our existing system.
That use case is one of the reasons I'd definitely like to see H2C supported. This is something we'll look at after v3 has shipped. Soonâ„¢.