how to build a webserver with grpc which can deal with http1.1 request?

[lwmo...@gmail.com]

hi:

Can the GRPC  service process HTTP1.1 request naturally? eg. a request from browser.   If not,  what can I do to support it? 

Or  is I'm using GRPC wrong? Is it not used for building a webserver?

Thanks very much~

[Yugui]

I'm not sure what you mean by "building webserver", but you can use grpc-gateway so that you can call gRPC methods with XMLHTTPRequest+JSON.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d1a0feb8-db01-44dc-b11d-258aa4973ee3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Anderson]

On May 12, 2015 1:35 AM, <lwmo...@gmail.com> wrote:
> Can the GRPC  service process HTTP1.1 request naturally?

This is possible but not supported by any of the implementations currently.

> eg. a request from browser.   If not,  what can I do to support it?

This is not generally possible since gRPC requires trailer support and browser APIs don't support trailers. Some new APIs are being added to browsers that may support trailers, so it may be possible in the future to use gRPC natively on the browser.

grpc-gateway is a possible solution though.

[lwmo...@gmail.com]

I mean, we have some server which communicate to each other with HTTP1.1, if I build a new server with GRPC, can it communicate with the old ones?  

My requirement seems same with RESTful style... 

grpc-gateway is GREAT!  But when will you support for C++  ~~    haha

 

在 2015年5月12日星期二 UTC+8下午9:57:37，Yugui Sonoda写道：

[lwmo...@gmail.com]

Ignore the browser thing,  if I send a HTTP POST request (eg. use python urllib)  to a GRPC server,  can it process it?  If yes, is there any example?  

Thank you very much ~ ~~~~ 

在 2015年5月12日星期二 UTC+8下午10:24:14，Eric Anderson写道：

[Nicolas Noble]

The gateway can be used in front of any server. You don't need to write your server in go. Think of it as a reverse proxy process between your webserver backend and front-end.

--

You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/9da4f9ad-bf3b-4e31-a795-8d32e7956b2a%40googlegroups.com.

[lwmo...@gmail.com]

It seems your grpc-gateway generate a reverse-proxy that is independent with the GRPC-server,  and it can be deployed to a different machine, is that true? 

在 2015年5月12日星期二 UTC+8下午9:57:37，Yugui Sonoda写道：

[Yugui]

Yes. It can be independently deployed wherever you want.
Also it is an independent process, so the implementation of grpc-gateway does not restrict the language in which you implement your service.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6b9f00fd-f5d3-4c52-9602-9a919aa2d2de%40googlegroups.com.

[lwmo...@gmail.com]

Clear,  thank you very much ~~ 

在 2015年5月13日星期三 UTC+8下午3:12:25，Yugui Sonoda写道：

[lwmo...@gmail.com]

Clear,  thank you very much ~~ 

在 2015年5月13日星期三 UTC+8下午3:10:33，Nicolas Noble写道：

[bra...@ifup.co]

On Tuesday, May 12, 2015 at 7:24:14 AM UTC-7, Eric Anderson wrote:

On May 12, 2015 1:35 AM, <lwmo...@gmail.com> wrote:
> Can the GRPC  service process HTTP1.1 request naturally?

This is possible but not supported by any of the implementations currently.

Is there a specification describing the right way to do this? We are discussing the issue for the Go bindings but we don't know what the specified way to support it is:

https://github.com/grpc/grpc-go/issues/75#issuecomment-95399303

Thank You,

Brandon

[Wolfgang Grieskamp]

This may not be exactly what you are looking for, but there is a spec how to map proto rpcs (and hence grpc) to HTTP JSON REST here. It is based on annotations of the proto. The grpc-gateway discussion here sheds some more light on this.

Google is using that spec to expose a dual HTTP JSON REST/RPC entry point for APIs via proxy, there are tentative plans to open source the related technologies, but nothing firm yet.

-- 

Wolfgang

--

You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f19bcbdc-9fab-4723-bf30-28562ab806a6%40googlegroups.com.

[xian...@coreos.com]

Actually, we want to use gRPC on the same port along with the HTTP 1.1 REST API. Then user can upgrade to use gRPC seamlessly. 

A proxy is not the ideal solution in this case.

Qi has a rough proposal here: https://github.com/grpc/grpc-go/issues/75#issuecomment-95376238 

This seems to be a wide solution than a Go specific thing.

Do you think we should open a new thread to discuss about this? 

[Eric Anderson]

On Sun, May 17, 2015 at 11:40 AM, <xian...@coreos.com> wrote:

Actually, we want to use gRPC on the same port along with the HTTP 1.1 REST API.

Most of the HTTP/2 gRPC spec would apply to HTTP/1.1. Primarily the RST_STREAM doesn't exist in HTTP/1, so it would become a connection close instead.

Then user can upgrade to use gRPC seamlessly. 

A proxy is not the ideal solution in this case.

A reverse proxy can still work well here, but is not "ideal." Not "bad," but not "ideal."

Qi has a rough proposal here: https://github.com/grpc/grpc-go/issues/75#issuecomment-95376238 

This seems to be a wide solution than a Go specific thing.

Sorta, but not really. I think it is mainly implementation-specific HTTP handling issues; not wire-protocol issues. gRPC is not a fundamentally special HTTP client or server. This is why a reverse proxy would have no trouble having mixed gRPC and "normal" HTTP traffic, independent of HTTP/1.1 or HTTP/2.

The problem is that gRPC is an advanced HTTP user and goes through a lot of effort to be efficient. Lots of HTTP API don't support trailers, efficient flow control (no thread blocking), cheap streams (no thread-per-stream model), and full duplex (send and receive at same time), which are all HTTP/1.1 things to some degree.

In Java, I'm expecting us to eventually be able to run as just a Netty handler and do path-based dispatching, similar to ServeMux in Go. I'm heavily redesigning the Netty HTTP/2 API to do that though, and we don't yet know the performance cost.

Doing something similar in Go seems very feasible (without the redesign), but there are lots of details, and the performance impact is hard for me to predict.

For the other languages though, all of this is probably out-of-scope for the foreseeable future. In the mean time (even for Java and Go), using a reverse proxy seems like a more-immediate approach.

[Adrià Casajús]

I don't think it's needed to implement HTTP/1.1. Just plain HTTP/2. Afaik there's a required header (Content-Type if I remember correctly) for gRPC calls. Can the server have a default handler for HTTP/2 streams that do not provide that required header?

Cheers,

 Adri

[Eric Anderson]

On Mon, May 18, 2015 at 5:34 AM, Adrià Casajús <ad...@ecm.ub.edu> wrote:

I don't think it's needed to implement HTTP/1.1. Just plain HTTP/2. Afaik there's a required header (Content-Type if I remember correctly) for gRPC calls. Can the server have a default handler for HTTP/2 streams that do not provide that required header?

Content-Type is a required header, and it is the primary way of ensuring that the client and server are both talking gRPC. However, to properly implement HTTP you should do path-based dispatching, because returning 404 must be independent of the Content-Type.

[xian...@coreos.com]

On Sunday, May 17, 2015 at 3:06:22 PM UTC-7, Eric Anderson wrote:

On Sun, May 17, 2015 at 11:40 AM, <xian...@coreos.com> wrote:

Actually, we want to use gRPC on the same port along with the HTTP 1.1 REST API.

Most of the HTTP/2 gRPC spec would apply to HTTP/1.1. Primarily the RST_STREAM doesn't exist in HTTP/1, so it would become a connection close instead.

Then user can upgrade to use gRPC seamlessly. 

A proxy is not the ideal solution in this case.

A reverse proxy can still work well here, but is not "ideal." Not "bad," but not "ideal."

Qi has a rough proposal here: https://github.com/grpc/grpc-go/issues/75#issuecomment-95376238 

This seems to be a wide solution than a Go specific thing.

Sorta, but not really. I think it is mainly implementation-specific HTTP handling issues; not wire-protocol issues. gRPC is not a fundamentally special HTTP client or server. This is why a reverse proxy would have no trouble having mixed gRPC and "normal" HTTP traffic, independent of HTTP/1.1 or HTTP/2.

The problem is that gRPC is an advanced HTTP user and goes through a lot of effort to be efficient. Lots of HTTP API don't support trailers, efficient flow control (no thread blocking), cheap streams (no thread-per-stream model), and full duplex (send and receive at same time), which are all HTTP/1.1 things to some degree.

In Java, I'm expecting us to eventually be able to run as just a Netty handler and do path-based dispatching, similar to ServeMux in Go. I'm heavily redesigning the Netty HTTP/2 API to do that though, and we don't yet know the performance cost.

I can image there are two issues here: 

1. determine HTTP version 

2. if it is HTTP2, then we need to determine plain HTTP2 or gRPC over HTTP2.

Are you suggesting to use path-based dispatching to solve 2? 

Thanks!

[Eric Anderson]

On Mon, May 18, 2015 at 8:53 AM, <xian...@coreos.com> wrote:

Qi has a rough proposal here: https://github.com/grpc/grpc-go/issues/75#issuecomment-95376238 

This seems to be a wide solution than a Go specific thing.

Sorta, but not really. I think it is mainly implementation-specific HTTP handling issues; not wire-protocol issues. gRPC is not a fundamentally special HTTP client or server. This is why a reverse proxy would have no trouble having mixed gRPC and "normal" HTTP traffic, independent of HTTP/1.1 or HTTP/2.

The problem is that gRPC is an advanced HTTP user and goes through a lot of effort to be efficient. Lots of HTTP API don't support trailers, efficient flow control (no thread blocking), cheap streams (no thread-per-stream model), and full duplex (send and receive at same time), which are all HTTP/1.1 things to some degree.

In Java, I'm expecting us to eventually be able to run as just a Netty handler and do path-based dispatching, similar to ServeMux in Go. I'm heavily redesigning the Netty HTTP/2 API to do that though, and we don't yet know the performance cost.

I can image there are two issues here: 

1. determine HTTP version 

2. if it is HTTP2, then we need to determine plain HTTP2 or gRPC over HTTP2.

Are you suggesting to use path-based dispatching to solve 2?

Yes. "gRPC over HTTP2" is very similar to "REST over HTTP2" or "web application over HTTP2" from a dispatching perspective.

If the API is mostly agnostic to HTTP version, then step 1 may not be necessary. From what I can tell, all the HTTP/2 specific stuff on server-side would be handled by a reasonable higher-level HTTP/2 server library normally or doesn't matter much on server-side.

[shrivin...@gmail.com]

Hi Liang,

Were you able to write the gRPC server in C++ which can talk via grpc-gateway which will get HTTP message from another web application 

[shrivin...@gmail.com]

Any example with C++ you know of will be very helpful.