I just started studying network and by network I mean the fundamental concepts and topologies.
I learned that currently the up-to-date version of HTTP is 2.0 and, according to my research, it seems that HTTP 2.0 is quite universal in the web environment.
But while checking the request and response message in my Chrome browser's mode, I found out that quite a lot of the messages(actually almost every message) were using HTTP 1.1. I tried with well-known web pages like FB, Google etc. but they were all using HTTP 1.1.
My question is, if HTTP 2.o is truly in general use, why are my messages in HTTP 1.1?
And if in fact a lot of messages are sent in HTTP 1.1, why is HTTP 2.0 still not used as people say?
Edited
I tried this way.
Here is the screenshot
Related
What are good "bad HTTP client"-s I can use to test your HTTP servers?
For instance, there are servers like
https://httpbin.org/
https://badssl.com/
which allow you to test client against different, sometimes intentionally bad, behavior.
I seek for HTTP client utility for testing HTTP servers. It may send wrong Content-Length or close connection in the middle of request, or do other bad things which robust HTTP server should handle.
In the past, I have used Tamper Data (for Firefox). I see that there is an equivalent for Chrome - Tamper Chrome.
These plugins allow you to edit the HTTP request prior to sending it to the server. This way you can do a number of test cases e.g.:
Changing the content length or type
Bypassing the client-side field validation
These are great for manual, exploratory testing.
Apparently we are turning off support of TLS < 1.2 in the near future. So, we would like to inform users that access our site, prior to the turn off, to upgrade their browsers.
Initially I looked at HowsMySSL.com, which has an API that can be accessed via Javascript, but ultimately we don't want to access a 3rd party API.
Is there not a server variable in ASP.NET, which indicates which cipher version has been handshaken between the client and server?
To reiterate, we haven't turned off TLS < 1.2 YET, but want to be proactive to inform those users that will be affected. So, the users will successfully negotiate the handshake, I'm just looking to get the value of the cipher used...
See this thread (oh the futility!): Check ssl protocol, cipher & other properties in an asp.net mvc 4 application
We haven't come up with a solution yet either. Though the SCHANNEL event-log parsing is looking like a promising way to at least get a feel for how many people are connecting with which protocol.
I am working on a C# mobile application that requires major interaction with a PHP web server. However, the application also needs to support an "offline mode" as connection will be over a cellular network. This network may drop requests at random times. The problem that I have experienced with previous "Offline Mode" applications is that when a request results in a Timeout, the server may or may not have already processed that request. In cases where sending the request more than once would create a duplicate, this is a problem. I was walking through this and came up with the following idea.
Mobile sets a header value such as UniqueRequestID: 1 to be sent with the request.
Upon receiving the request, the PHP server adds the UniqueRequestID to the current user session $_SESSION['RequestID'][] = $headers['UniqueRequestID'];
Server implements a GetRequestByID that returns true if the id exists for the current session or false if not. Alternatively, this could returned the cached result of the request.
This seems to be a somewhat reliable way of seeing if a request successfully contacted the server. In mobile, upon re-connecting to the server, we check if the request was received. If so, skip that pending offline message and go to the next one.
Question
Have I reinvented the wheel here? Is this method prone to failure (or am I going down a rabbit hole)? Is there a better way / alternative?
-I was pitching this to other developers here and we thought that this seemed very simple implying that this "system" would likely already exist somewhere.
-Apologies if my Google skills are failing me today.
As you correctly stated, this problem is not new. There have been multiple attempts to solve it at different levels.
Transport level
HTTP transport protocol itself does not provide any mechanisms for reliable data transfer. One of the reasons is that HTTP is stateless and don't care much about previous requests and responses. There have been attempts by IBM to make a reliable transport protocol called HTTPR what was based on HTTP, but it never got popular. You can read more about it here.
Messaging level
Most Web Services out there still uses HTTP as a transport protocol and SOAP messaging protocol on top of it. SOAP over HTTP is not sufficient when an application-level messaging protocol must also guarantee some level of reliability and security. This is why WS-Reliability and WS-ReliableMessaging protocols where introduced. Those protocols allow SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures. At the same time they provide additional security. You can read more about those protocols here and here.
Your solution
I guess there is nothing wrong with your approach if you need a simple way to ensure that message has not been already processed. I would recommend to use database instead of session to store processing result for each request. If you use $_SESSION['RequestID'][] you will run in to trouble if the session is lost (user is offline for specific time, server is restarted or has crashed, etc). Also, if you use database instead of session, you can scale-up easier later on just by adding extra web server.
WWDC 2012 session 706 - Networking Best Practices explains HTTP Pipelining.
By default its disabled on iOS
In the talk its described it as a huge performance win.
Why might you not want to use it?
Implementation bugs
For pipelining to work, responses must come back in the order they were requested. A naive server implementation might just send the response as soon as it has been calculated. If multiple requests are sent in parallel, and the first request one takes longer to process (e.g. processing a larger image), then the responses will be out of order.
This is a problem for the client since HTTP is a stateless protocol, the client has no way to match the requests with the responses. It is reliant on the order the responses came back in.
A server MUST send its responses to those requests in the same order that the requests were received.
Safari apparently used HTTP pipelining for images at least. This results in an issue where images would be swapped around.
AFNetworking used to use pipelining, but it was pulled after a reported issue.
All major browsers (other than Opera) have HTTP pipelining is disabled or not implemented.
Performance issues
Even if the server does properly support pipelining, performance issues can arise because all subsequent requests have to wait for the first one to be complete (Head of Line blocking).
This article, talks about performance loss in some circumstances and a potential of denial of service attack.
This article also suggest that pipelining isn't a massive win.
WWDC 2015 - Networking with NSURLSession explains head of line blocking really well. (The solution is to switch to HTTP 2 which support priorities)
So in summary the issues with HTTP pipelining are:
Some servers & most proxies don't support it. (Perhaps due to security / reliability / or performance concerns)
Some servers support it incorrectly and this can lead to client bugs.
It is not necessarily a performance win.
Susceptible to head of line blocking
I'm implementing a basic http client for communicating with a web service and am wondering if I should go with http 1.0 or 1.1.
The data section will consist of binary data and the remote server will always be controlled by me (running IIS7.5). The firewalls / proxies inbetween is nothing I'm controlling, ie. the packets must not be stopped if wrong http version is used.
I've been reading up about the difference between http 1.0 and 1.1 and it seems to me that http 1.0 supports everything I need.
Will I encounter problems if i choose http 1.0 over 1.1 or can I assume that everything will work just as good?
What makes me wonder is that if I connect via raw sockets to IIS7.5 and send a http 1.0 get request, the response is always http 1.1.
A firewall certainly will not block it and a router will route it.
I would suggest using HTTP 1.1. Chances are nothing will be affected if you use HTTP 1.0. However, you never know who else might use your HTTP client in the future and what horrible server implementation it will be used with.
You also need to ask yourself why you are implementing an HTTP client in the first place. Why not just use a standard library? I do not know what language you are using, but libcurl has bindings for many languages.
You can see more about libcurl here.
I don't think there's anything wrong using 1.0 as a client, most web servers are backward compatible.
If you're really have concerns, send 1.1 and only deal with stuff you want to handle, I don't think there's anything possibly go wrong choose either case.