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.
Related
Is it possible to modify Ocserv on clients so that it runs on plain http instead of ssl and use a simple XOR or a custom encryption?
I know that it is insecure but in my case I don't care about security and TLS overhead (including handshaking time) and also SSL censorship are major concerns.
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.
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 managing a web application that dynamically flips between http and https depending on the page. I want to get rid a ton of extra code used to flip between http and https but I want to understand any implications before I continue.
Is there any advantage to serving part of a site using http over https?
Of course there is some performance drop when using https, but it is not significant unless you have an extremely busy server. See
HTTP vs HTTPS performance
HTTP is not a secure protocol and anyone can intercept the transmitted data in cleartext (e.g. session cookies, passwords, credit card numbers, sexual fetishes). If you can, you should provide consistent HTTPS service throughout.
That said, by the design of the public/private key security, you can only use HTTPS on a server where you have complete and sole control over the IP address, since the client first looks up the IP address, then requests the secure protocol, and only then makes the HTTP query. That means that you cannot deploy HTTPS on virtual hosts (shared hosting).
(Since you already have a partial HTTPS solution, I imagine that's not a problem for you, though.)
The other downside is that the secure handshake and later encryption require computing resources, so that if you have bazillions of connections, you may feel quite a hit on your server performance. That's for you to consider, though.
Short form: If you have a dedicated IP address and enough computing resources, always and exclusively use HTTPS.
Using http is faster than https obviously since you do not have the ssl handshake overhead during connection establishment or the extra encryption/decryption delay.
If you only need parts of your web site to be secure e.g. just encrypt the login credentials, then it makes sense to have the code for the redirection so that the interaction after that is faster due to plain-text http.
If there are many areas of your site that need to be secure, then you could make measurements using https completely and see if the performance is significantly affected.
If you see no significant performance issues (or the performance is acceptable), then you could simplify your software design and remove the redirection logic between http<->https and use https everywhere.
One of the differences between HTTP and HTTPS is that with HTTPS, you loose the ability to have intermediaries (caches, proxies, etc) between the client and server do anything useful with requests and responses because the content is encrypted. From a security point of view, this is a good thing because it prevents intermediaries from snooping or tampering with traffic. On the other hand, you reduce the opportunities for dealing with things like scalability, performance and evolvability.
The HTTP 1.1 RFC restricts a Client from using more than Two TCP connections between any Client and Server. I want to know which Web Application Frameworks enforce this restriction.
Regards
The HTTP 1.1 implementation is not a function of the web application framework, it's a function of the client or server HTTP agent. In other words, it's implemented by Safari, Chrome, Firefox and Internet Explorer on the client side, and Apache or IIS on the server side [*]. Of course, there are a lot more HTTP agents out there that also implement HTTP 1.1; I am just listing the most popular (as in "that I use" :-)) ones.
As far as I know, most of the web application frameworks listed on that Wikipedia article you linked to should happily run on top of Apache and/or IIS at least, so they should be able to benefit from HTTP 1.1. However, if the browser the user is using does not support HTTP 1.1, the default configuration for Apache and IIS will be to fallback to HTTP 1.0, and that will happen transparently to the web app framework of your choice in the most common case.
Update: Your question should be paraphrased (as per your comment) to "Which web application frameworks support only HTTP 1.1 as transport protocol".
There are no major web service frameworks that enforce endpoint configurations or client calls over HTTP 1.1 only. All of them allow the application code (service or client) to choose the transport. There are two main reasons for this:
the protocol choice depends on the deployment configuration of the actual service, so it's orthogonal to the framework used and is rarely made by the web service developer
limiting the transport protocol choice to HTTP 1.1 by the framework means increased adoption barrier, which no framework author would want.
The only frameworks that might enforce particular HTTP version would be ones that come with either their own implementation of the web server or with pre-configured deployment of a major web server (usually Apache). However, I am not aware of any that would enforce HTTP 1.1 only; if anything, they would enforce HTTP 1.0 only.
There is also one very practical reason that prevents HTTP 1.1 enforcementfor web services in general - most deployments are expected to work across an unknown number of middle gateways (firewalls, caching servers, load balancers and so on) which might or might not support HTTP 1.1, so the protocol negotiation between the web service client and the web service endpoint fail without fallback support for HTTP 1.0.
[*] Well, technically, it's implemented by WinHTTP and WinInet on Windows platform and is just reused by the applications. And I am sure there's a common library that is reused on Linux as well (probably called libhttp.so or something like it, but don't quote me on that :-)).