What is the smallest possible http and https data request

Question

Lets say I want to GET one byte from a server using the http protocol and I want to minimize everything, no headers just http://myserver.com/b where b is a text file with one ch

Answer 1

What exactly are you trying to achieve, is this a sort of keep alive?

You could do a "GET /", which implies HTTP/1.0 being used, but that locks you out of stuff like virtual hosting etc. You can map "/" to a cgi-script, it doesn't need to be a real file, depending on what you're trying to achieve. You can configure Apache to only return the minimum set of headers, which would basically be "Content-Type: text/plain" (or another, shorter mime type, possibly custom mimetype e.g. "Content-Type: a/b") and "Content-Length: 0", thus not returning a response body at all.

Answer 2

If you're planning to use HTTP/1.1 (more or less require if you end up on a virtual host), your GET request will need to have the host name, either in the Host header or as an absolute URI in the request line (see RFC 2616 section 5.1.2).

Your response will also need a Content-Length or transfer encoding headers and delimiters.

If you're willing to "break" HTTP by using a HEAD request, it sounds like HTTP might not be the best choice of protocol. You might also be able to return something in a custom header, but that's not a clean way of doing it.

Note that, even if you implement your own protocol, you will need to implement a mechanism similar to what Content-Length or chunked encoding provide, to be able to determine when to stop reading from the remote party (otherwise, you won't be able to detect badly closed connections).

EDIT:

Here is a quick example, this will vary depending on your host name (assuming HTTP 1.1). I guess you could use OPTIONS instead. It depends on how much you're willing to break HTTP...

Request:

GET / HTTP/1.1
Host: www.example.com

That's 14 + 2 + 21 + 2 + 2 = 41 bytes (2 for CRLF)

Response:

HTTP/1.1 200 OK
Content-Length: 1
Content-Type: text/plain

a

That's 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 bytes

For HTTPS, there will be a small overhead for the SSL/TLS channel itself, but the bulk of it will be taken by the handshake, in particular, the server certificate (assuming you're not using client-cert authentication) should be the biggest. Check the size (in DER format) of your certificate.

Answer 3

It is an old question, but maybe someone found it useful, because nobody has answered the HTTPS part of the question.

For me this was needed for an easy validation of HTTPS communication in my proxy, which connects untrustable other proxies through tunnel.

This site explains it clearly: http://netsekure.org/2010/03/tls-overhead/

Quotes from the article:

One thing to keep in mind that will influence the calculation is the variable size of most of the messages. The variable nature will not allow to calculate a precise value, but taking some reasonable average values for the variable fields, one can get a good approximation of the overhead. Now, let’s go through each of the messages and consider their sizes.

• ClientHello – the average size of initial client hello is about 160 to 170 bytes. It will vary based on the number of ciphersuites sent by the client as well as how many TLS ClientHello extensions are present. If session resumption is used, another 32 bytes need to be added for the Session ID field.
• ServerHello – this message is a bit more static than the ClientHello, but still variable size due to TLS extensions. The average size is 70 to 75 bytes. -Certificate – this message is the one that varies the most in size between different servers. The message carries the certificate of the server, as well as all intermediate issuer certificates in the certificate chain (minus the root cert). Since certificate sizes vary quite a bit based on the parameters and keys used, I would use an average of 1500 bytes per certificate (self-signed certificates can be as small as 800 bytes). The other varying factor is the length of the certificate chain up to the root certificate. To be on the more conservative side of what is on the web, let’s assume 4 certificates in the chain. Overall this gives us about 6k for this message.
• ClientKeyExchange – let’s assume again the most widely used case – RSA server certificate. This corresponds to size of 130 bytes for this message.
• ChangeCipherSpec – fixed size of 1 (technically not a handshake message)
• Finished – depending whether SSLv3 is used or TLS, the size varies quite a bit – 36 and 12 bytes respectively. Most implementations these days support TLSv1.0 at least, so let’s assume TLS will be used and therefore the size will be 12 bytes

So the minimum can be as big (or small) as:

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249

Though according to the article, the average is about 6449 bytes.

Also it is important to know that TLS sessions can be resumed, so only the 1st connection has this overhead. All other messages have about 330 bytes plus.