Support serving web content from the same port

[tv42]

https://github.com/grpc/grpc-common/blob/master/PROTOCOL-HTTP2.md#appendix-a---grpc-for-protobuf says grpc protobuf mapping uses service names as paths. Would it be possible to serve web content from other urls?

I see TLS side does alpn, so that's an easy place to hook up.

Any thoughts about non-TLS? e.g. a service running on localhost. Of course that would mean needing to do a http/1 upgrade negotiation, as then the port could not default to http/2.

Use case 1: host a web application and its api on the same port.

Use case 2: serve a health check response.

Use case 3: serve a "nothing to see here" html page.

Use case 4: serve a /robots.txt file.

[tv42]

I just realized the grpc tls alpn is just HTTP/2 drafts, not a separate protocol. Scratch that plan; the splitting of grpc vs other needs to happen more per-{request|stream|something}.

[stapelberg]

I’d be interested in this as well.

[acasajus]

Since there's no grpc/grpc-experiments#152 Can there be a failover stream handler? If the grpc server cannot process the stream (the service/method doesn't exist for instance) we could have another handler that devs can define to process it.

[iamqizhao]

Yup, I think adding some additional handlers for non-grpc content is the way to go just like what we have done for google internal rpc framework. I will raise it to design discussion and get back to you once we have a decision.

[acasajus]

From grpc/grpc-experiments#152: There's a mandatory content type for grpc. So streams that do not have it can be served by the default http handler.

[acasajus]

Any news on this? Should we go ahead and make a PR?

[xiang90]

I am also interested in this one.

/cc @xiang90 @yichengq

[xiang90]

@iamqizhao Have you had the discussion yet? Any decision? Anything I can help to make this happen?

[iamqizhao]

I think this is good to have. But I do not see a compelling demand to have
it now given a lot of other stuffs I am working on. So it is on my radar
but a low priority item. I will be more than happy to take a PR from you
guys.

On Wed, Apr 22, 2015 at 10:53 AM, Xiang Li notifications@github.com wrote:

@iamqizhao https://github.com/iamqizhao Have you had the discussion
yet? Any decision? Anything I can help to make this happen?

—
Reply to this email directly or view it on GitHub
#75 (comment).

[xiang90]

@iamqizhao I can work on it.

Motivation:

1. currently etcd and a few other my side projects have a http1 endpoint as it API.
2. I want to support GRPC in the next few releases without adding a new port or break compatibility.

So ideally, grpc can forward http1 requests to my old handlers. But can you give me some direction to do that? I can start to explore and hopefully have a pr for it.

[iamqizhao]

On Wed, Apr 22, 2015 at 11:16 AM, Xiang Li notifications@github.com wrote:

@iamqizhao https://github.com/iamqizhao I can work on it.

Motivation:

1. currently etcd and a few other my side projects have a http1
   endpoint as it API.
2. I want to support GRPC in the next few releases without adding a
   new port or break compatibility.

So ideally, grpc can forward http1 requests to my old handlers. But can
you give me some direction to do that? I can start to explore and hopefully
have a pr for it.

grpc-go uses bradfitz/http2 package to write & read http2 frames. I suspect
the framer.ReadFrame will error out if it receives a http1 request (need
look into the code or check with brad). If it is the case, it is not
trivial to implement this feature without some change to http2 package...

You can probably check https://github.com/gengo/grpc-gateway to see if
there is alternative to your problem.

—
Reply to this email directly or view it on GitHub
#75 (comment).

[xiang90]

@iamqizhao

It seems @bradfitz's http2 server supports both http1 and http2 at the same time. Here is the related code

https://github.com/bradfitz/http2/blob/91f80303028022bc2034c277126b405a2257d990/server.go#L185-L192

Are we able to do the similar thing?

[iamqizhao]

On Wed, Apr 22, 2015 at 4:04 PM, Xiang Li notifications@github.com wrote:

@iamqizhao https://github.com/iamqizhao

It seems @bradfitz https://github.com/bradfitz's http2 server supports
both http1 and http2 at the same time. Here is the related code

https://github.com/bradfitz/http2/blob/91f80303028022bc2034c277126b405a2257d990/server.go#L185-L192

Yep, the idea is to push the divergence stage (http1 or http2) before there
is any real traffic. It uses the usage NPN/ALPN to decide whether
http.Server creates a http2 ServerConn and dispatches the traffic there.
http1 traffic can never enter http2 package. If we put grpc into this
picture, there are grpc, http2 and http1 handlers. Then the usage of
NPN/ALPN is not enough to make decision which server conn we should setup
(apparently no idea between http2.ServerConn and grpc.ServerTransport; and
actually I am not convinced using NPN/ALPN is sufficient for http1 and
grpc). To summarize, to design a working solution, we have to find
something which can be used to see the upcoming traffic on the connection
is http1/http2/grpc. NPN/ALPN seems not the choice to me.

Are we able to do the similar thing?
Can

—
Reply to this email directly or view it on GitHub
#75 (comment).

[iamqizhao]

okay, my proposal is sketched as follows:

we can implement a handshaker. The client connects to a http.Server and
then sends a http1.1 GET with some magic string such as "gRpC-sWiTcH". The
corresponding handler will pass that fd to a grpc server (and response to
the client via handshaker too). After that, all the traffic on that fd is
taken care of by the grpc server. Otherwise, the normal http handler will
be used.

On Wed, Apr 22, 2015 at 4:33 PM, Qi Zhao toqizhao@gmail.com wrote:

On Wed, Apr 22, 2015 at 4:04 PM, Xiang Li notifications@github.com
wrote:

@iamqizhao https://github.com/iamqizhao

It seems @bradfitz https://github.com/bradfitz's http2 server supports
both http1 and http2 at the same time. Here is the related code

https://github.com/bradfitz/http2/blob/91f80303028022bc2034c277126b405a2257d990/server.go#L185-L192

Yep, the idea is to push the divergence stage (http1 or http2) before
there is any real traffic. It uses the usage NPN/ALPN to decide whether
http.Server creates a http2 ServerConn and dispatches the traffic there.
http1 traffic can never enter http2 package. If we put grpc into this
picture, there are grpc, http2 and http1 handlers. Then the usage of
NPN/ALPN is not enough to make decision which server conn we should setup
(apparently no idea between http2.ServerConn and grpc.ServerTransport; and
actually I am not convinced using NPN/ALPN is sufficient for http1 and
grpc). To summarize, to design a working solution, we have to find
something which can be used to see the upcoming traffic on the connection
is http1/http2/grpc. NPN/ALPN seems not the choice to me.

Are we able to do the similar thing?
Can

—
Reply to this email directly or view it on GitHub
#75 (comment).

[bakins]

Why not use HTTP Upgrade?