views:

1690

answers:

11

What hidden features of HTTP do you think are worth mentioning?

By hidden features I mean features that already are part of the standard but widely rather unknown or unused.

Just one feature per answer please.

+53  A: 

It's got to be the 418 I'm a teapot status code, part of the Hyper Text Coffee Pot Control Protocol (an extension to HTTP). Makes me laugh every time.

2.3.2 418 I'm a teapot

Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.

Greg Beech
That is awesome!
Josh
I have actually implemented this status in a script for when no other status is appropriate.
eyelidlessness
From the RFC: "The resulting entity body MAY be short and stout."
Piskvor
I wrote my own HTTP server and made sure to implement this.
Matt Joiner
Was this not a real protocol they had written for sending commands to there coffee machine, Im sure I read that somewhere ! - They built a coffee machine to accept commands via this protocol, so in fact its a legitimate protocol
RobertPitt
+26  A: 

Obvious answer: PUT, DELETE, TRACE, OPTIONS, CONNECT methods

Most people know about the GET and POST methods because that's what they use when building forms. Browsers also use HEAD a lot. The other methods are much less well-known; they are mostly used by more specific applications.

Martijn
Nice answer, could you provide more info on all of the methods?
Louis
You can read all about it on various sites, such as http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Martijn
+15  A: 

Have anyone ever seen 402 Payment Required?

raspi
Yes. In HTTP<->SMS gateway. If you run out of pre-paid credit, you'll start getting 402 responses.
porneL
"This code is reserved for future use." Whoops...
zildjohn01
@zildjohn01: That means ... *dramatic pause* ... THAT WE'RE LIVING IN THE FUTURE! ;)
Piskvor
@Piskvor: Brilliant observation. I'll also point out that I reject this future, and it's pathetic software stacks.
Matt Joiner
+12  A: 

In Dynamic content use Last_Modified or ETag header

At times you have dynamic content that can be large and/or costly to generate and that may not change from request to request. You can add a Last_Modified or ETag header to the your generated response.

At the top of your expensive dynamic code you can use the If_Modified_Since or the If_None_Match to determine if the content requestor already has is still current. If it is change the response status to "304 Unmodified" and end the request.

Some server-side technologies provide such features formally but you can do the above even in lowly ASP-Classic.

Note this differs from setting Cache-Control, Expires headers in that it ensures the client always has the latest info on request.

AnthonyWJones
+6  A: 

The protocol allows you to define your own custom-fields. These can be used to carry other information if you don't want to use cookies for it.

sybreon
+8  A: 

ReST tries to push HTTP to its limits as an interface protocol.

It's not a hidden feature, but from looking at well-defined ReST APIs one can get quite a nice grip on how HTTP is meant to work and find wonderful examples of what can be achieved with simple combination of HTTP methods, status codes and headers to and fro.

Boldewyn
+12  A: 

204 No Content

I thought 204 was just if you have no content to display, but the spec looks like there is additional behavior that the user agent "not change its document view."

According to HOWTO: Configure Apache to Return a HTTP 204 (No Content) for AJAX

FWIW, Google actually does something similar. Each time a user clicks on a link in their search results, Google pings itself to record the click; the response code from the ping is an HTTP 204.

Also, 204 No Content proposes this is a good technique for "web bugs" or "beacons" if you want to save on every last byte of network traffic you can.

Kevin Hakanson
+12  A: 

The fact that referrer was misspelled and it was decided that the misspelling should be kept.

George Edison
+5  A: 

You can request to resume a (large) HTTP response (e.g. file download) using Range and If-Range request headers with respectively the specified byte range and the unique file identifier or the file modification timestamp. This is possible if the server has sent the Accept-Ranges: bytes and ETag or Last-Modified response headers on the initial response with respectively the notification that the server supports byte range requests, the unique file identifier and the file modification timestamp.

The initial response can look like (the ETag is usually composed of file name, size and last modification timestamp):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

When the download get aborted on for example 1KB (1024 bytes), the client can resume it as follows:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Which should return this response with the appropriate bytes in the body:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234
BalusC
1Mbyte = 1024 kbytes, 1kbyte = 1024 bytes, that makes 1Mbyte = 1024*1024 bytes
Maerlyn
@Maerlyn: Oops. Fixed.
BalusC
+5  A: 

Response Code 410 Gone:

(...) server owners desire that remote links to that resource be removed. (...)

Web spiders (most notably Google) will de-index (typically on next crawl) a page which starts returning 410.

Piskvor