#1428 make http/2 --next use a new stream

[Scott Mitchell]

The --next flag for HTTP/2 does not result in requests on a new stream (when --next URL is the same as previous URL). Instead it looks like curl is attempting to open a new connection which results in SSL connection error (like the following):

SSL/TLS handshake error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

[Scott Mitchell]

Ignore the handshake error portion of this issue. That was my mistake. I forgot to pass the -k option a second time.

[Scott Mitchell]

The title is also a bit misleading...this is not necessarily an error but more of a feature request or enhancement to go along with HTTP/2's new abilities.

[Daniel Stenberg]

So what is the error here?

[Scott Mitchell]

So the issue is really a feature request. The --next option for HTTP/2 is opening a new socket for each request. The feature request is to use a new stream (instead of opening a new connection) when the request URLs make sense to do so.

[Daniel Stenberg]

First, --next does not (necessarily) make an other connection. It makes another transfer and that transfer can re-use a connection or create a new one.

Then, I don't see any good motivation why --next would impose some special magic on which stream the next request to be done over, as that's a very specific HTTP/2 implementation detail. What's your motivation for wanting a new stream on demand?

Finally: as far as my reading of the http2 spec goes, isn't all new requests over the same physical connection going to use a new stream anyway?

[Scott Mitchell]

First, --next does not (necessarily) make an other connection. It makes another transfer and that transfer can re-use a connection or create a new one.

How can I force curl to re-use a connection (specifically in http2 mode)?

Then, I don't see any good motivation why --next would impose some special magic on which stream the next request to be done over, as that's a very specific HTTP/2 implementation detail. What's your motivation for wanting a new stream on demand?

Re-using a connection is the motivation. As I understand it this was one of the primary reasons HTTP/2 was developed. You are welcome to make a new feature to accomplish this if it makes more sense, --next just seemed to naturally lend itself to this.

Finally: as far as my reading of the http2 spec goes, isn't all new requests over the same physical connection going to use a new stream anyway?

Yes. This is the point. I would like to re-use a connection to issue multiple requests which should result in a new stream for each request. Is there a way to do this today?

[Daniel Stenberg]

curl already re-uses the connection on its own and by default, no need to do anything. Try this for a simple example:

$ curl -v --http2 https://nghttp2.org/ https://nghttp2.org/

If the server however closes the connection after the first request or otherwise denies a connection re-use, then it will of course create a new connection for the second transfer.

[Scott Mitchell]

I think I'm getting closer to what I'm trying to do with your help ;). Is there a way to set 2 different POST request bodies for each request?

For example I have tried the following:

$ curl -i --http2 -k 'https://10.0.2.2:13443/proxy/address' -H "accept: application/vnd.akamai.query" -d '<json object>' https://10.0.2.2:13443/sql' -d '<opaque data>'

However I'm seeing some strange behavior. I'm seeing 2 connections being made. The first connection appears to correctly open 2 streams (one for each request with the first stream using the HTTP upgrade stream) however the POST request body seems to be combined as <json object>&<opaque data> for both requests. The second connection just has 1 stream which corresponds to the second URL (/sql) but again with POST body being a combination of the two.

[Daniel Stenberg]

This is not a bug but has turned into a support issue or series of issues. This is detailed in the curl man page and if you need general help on how to use the curl too, the curl-users mailing list is there. I consider this case closed.