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
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.