gRPC is based on HTTP/2, which (assumption) is widely supported by browsers. Therefore, I feel there should be no problem with gRPC from a browser.
However, it is clear that there is a problem. The protocol, grpc web, is different, as exists "due to browser limitation". There are also numerous blog post describing complicated tech stacks deployed to get gRPC to work from a browser.
I'm missing the actual problem - why does gRPC not simply work from browsers?
I now understand that browsers only supports HTTP/2 in the sense that they use it to fetch resources from the server on behalf of your application (javascript) code.
Javascipt application code can still only use HTTP/1 (which may be handled under the hood by the browser in an HTTP/2 connection). Therefore it is not possible for application code to use grpc.
If anyone should find where this is explained in the docs, it would be good to add a link to it here.
Most browsers use HTTP1.1 whereas GRPC only works with HTTP2. You can use nginx, envoy or traefic to run it behind a reverse proxy, very similar to how web sockets are often used behind a reverse proxy(in that case the http1 is upgraded to a websockets connection). The reverse proxy will send the grpc request sent over http1 to an http2 backend and vice versa. You can use Envoy(suggested/currently used by grpc-web), traefik(am using this personally) and nginx.
Related
I'm trying to connect to a grpc-service from a Java client. The problem is that this service is currently supporting only grpc-web over http1.1, this is because of a limitation of supporting http2 in Azure App service where the service is deployed.
The grpc-java client liberary from io.grpc only supports grpc over http2 protocol, which maskes sense, and unfortenatly is not working for me.
I managed to consume a service using HTTP client from apache and okhttp3 but this works for unary calls and it didn't work for a server-side streaming service.
Is any one aware of a grpc-web java client liberary that I could use or a work arround using convenienal Http for reading grpc-web server-side streaming service.
If I understand your question correctly, you want a Java client for gRPC-Web so that your client can talk HTTP/1.1 through a gRPC-Web proxy (e.g. Envoy gRPC-Web) because you're unable to talk HTTP/2 directly to your service because of the Azure networking limitation?
In theory this should be possible. The JavaScript implementation is because, in-browser, there's no alternative except JSON transcoding. The JavaScript implementation does implement server-side streaming, which is another requirement and confirms that this should be possible over HTTP/1.1.
However, in a quick search I found no other (i.e non-JavaScript) client implementations of gRPC-Web.
If the browser supports http/2, why does grpc-web require envoy proxy?
Is it just required for older browsers that do not support http/2?
Answered in https://github.com/grpc/grpc-web/issues/347. For gRPC-Web to work, we need a lot of the underlying transport to be exposed to us but that's not the case currently cross browsers. We cannot leverage the full http2 protocol given the current set of browser APIs.
I try understand how http work's and can't understand on which level http protocol implemented, it's OS level, or it's depend from where I need use it protocol? For example if I want use it on C I must implement it on C language as library and only then use it?
Http runs on top of tcp - and tcp is implemented in the network stack of your OS.
Http protocol is used between a client and a server. What a client sends is what a server receives, and vice-versa. Http was designed for the server to simply sit and wait for requests (possibly including data), and then respond (possibly including data).
All web servers implement the server side of http. In terms of applications (let's use the term "application" to mean "client", although some might say the server is an application), the client side of http protocol will, I suppose, most commonly be implemented in an application like a browser, but also command-line applications like curl and wget implement an http client. For languages such as Python there is a http server implementation in the standard library, or there are libraries such as requests which handle the client side of http so the python author just worries about the higher-level problem of which http requests to make.
So the answer is, http is not implemented in the OS, it is implemented in applications - some client-side, some server-side.
For your C application you will either have to implement http yourself (doesn't sound like fun to me but would be a good way of understanding http implementation, I suppose) or (much less stress and much more likely to have predictable correctish behaviour) use a library if you can find one.
I am designing a RESTful web service. It will include some GET and POST requests. I am a bit confused whether the web service can benefit from SPDY protocol. I intend to use Ruby on Rails for the implementation. Are there any gems that support SPDY?
Potentially, yes.
One of the major design goals of SPDY is to reduce and amount of latency associated with each request. The way this is accomplished is by enabling multiplexing over the same TCP connection. Additionally, SPDY does header compression, which is a big win especially for REST style interactions which often cary very small (JSON) payloads, but send large HTTP headers (cookies, etc).
So, would SPDY give you a performance boost? It depends on your application, but there are specific optimizations within SPDY which should definitely help.
As far as "gems" for Ruby. There is the spdy gem which parses the protocol, but you shouldn't need it. SPDY is a layer below HTTP and should be mostly handled for you by the server. If you're interested in experimenting with it and you're using Rails, I would recommend trying Passenger + mod_spdy.
SPDY has nothing to do with the application itself. If you're using Apache, check mod_spdy. There is also SPDY daemon for rack.
I need to track http/url requests & redirects from a windows forms application using C#. It should handle both IE & firefox. Not sure if Fiddler is open-source but if i'm not mistaken, it's written using .NET. Sample codes or online articles on how to listen to http/url requests & redirects will be appreciated.
Thanks!
Fiddler works as standard HTTP proxy. There is no magic here. See HTTP protocol for details. In both IE/Firefox, you need to set Fiddler (or your custom program) as proxy, and then browser will use it for all outgoing requests. Proxy is responsible for forwarding request to correct server, and returning response. Proxies are typically used for 1) caching, 2) controlling access (and avoiding firewalls), 3) debugging.
See also Open Source Proxy Library for .Net for .NET proxy library (just quick googling... I have no experience with it).
You'd probably be interested in the new FiddlerCore library: http://fiddler.wikidot.com/fiddlercore