87

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.

Ben Brocka
  • 2,006
  • 4
  • 34
  • 53
Gumbo
  • 643,351
  • 109
  • 780
  • 844

13 Answers13

124

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
  • 133,383
  • 43
  • 204
  • 250
48

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

Nathan Osman
  • 71,149
  • 71
  • 256
  • 361
42

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
  • 6,713
  • 3
  • 31
  • 38
29

Have anyone ever seen 402 Payment Required?

raspi
  • 5,962
  • 3
  • 34
  • 51
25

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
  • 41,386
  • 23
  • 126
  • 155
17

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 left the building
  • 91,498
  • 46
  • 177
  • 222
16

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
  • 187,081
  • 35
  • 232
  • 306
13

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
  • 1,082,665
  • 372
  • 3,610
  • 3,555
12

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.

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
Boldewyn
  • 81,211
  • 44
  • 156
  • 212
9

Trailer (in contrast to Header)

Ebrahim Mohammadi
  • 344
  • 3
  • 11
8

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
  • 3,128
  • 18
  • 19
6

HTTP 100 (Continue) Status

A client can send a request message with a request body to determine if the origin server is willing to accept the request..

In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.

Could be used to avoid traffic from rogue clients.. and/or where bandwidth is a precious commodity.

However, for full use of this feature there are some criteria for HTTP1.1 Client, Servers and Proxies. See the HTTP/1.1 RFC 2616 for further reading on HTTP Connections.

Robin Maben
  • 22,194
  • 16
  • 64
  • 99
3

Status codes :

  • When URI http://www.domain.invalid/index.php?id=44 is called, if the query (id=44) couldn't return ressource, why not return a status code 404?
  • When URI http://www.domain.invalid/index.php?id=foo is called whereas id only accepts integers, why not return a status code 400?
  • Why, when you enter the wrong login/password, almost all web application return a message like "Authentication failed" with status code 200 (ok, no problem, you do it well) instade of 401?

Yes, status codes seems to be a kind of secret functionality of HTTP to some web developers... But I wonder if the most occult of all the "features" of this protocol isn't its RFC!

Community
  • 1
  • 1
Pascal Qyy
  • 4,442
  • 4
  • 31
  • 46
  • 2
    I think `401` is only for HTTP-Authentication and not other kinds. Afaik it causes most browsers to ask the user for a http password. – CodesInChaos Nov 06 '10 at 11:18
  • You're right, and this is the point! Here is an other "hidden" feature of HTTP: `HTTP-Authentication`... ^^ Is it so hard to use it instead of reinvent the wheel ? – Pascal Qyy Nov 06 '10 at 11:24
  • 1
    @G. Qyy: For a web application, it makes a big difference whether its user database is stored in some SQL database, which it can easily manipulate, or in some (fairly static) webserver configuration file, such as Apache's `.htaccess` files -- which probably only a webmaster can update. Thus HTTP auth is not actually very fit for managing an application's user rights and login/logoff. – stakx - no longer contributing Nov 06 '10 at 16:49
  • 4
    @stakx: It's easy to use MySQL (http://www.howtoforge.com/mod_auth_mysql_apache2_debian), LDAP or others to store informations for `HTTP-Authentication`, And even PHP is able to handle `HTTP-Authentication` (http://www.php.net/manual/en/features.http-auth.php). If you are a web developer, you have to get the basics of server administration, only for safety reasons! As web developer must to have webmaster/sysadmin skills he can easily perform this tasks. – Pascal Qyy Nov 06 '10 at 17:33
  • 1
    But anyway this is not about my answer: for me the main problem remains the almost systematic incorect status-codes returned by web apps, even putting aside the HTTP authentication. – Pascal Qyy Nov 06 '10 at 17:41
  • Is there a way to log out of HTTP-Authentication yet? Will it still pop up a modal dialog locking the entire browser until you give a response, which will be sent, no matter what you do? – XTL Feb 17 '12 at 08:03
  • in the first bullet, 404 would mean that index.php does not exist on the server. in the third bullet, 200 is correct because the server has been able to tell you that you entered wrong login/password in the web app. 401 would mean you have to authenticate your client to the server before being provided the login form in the webapp. – Alex Jul 10 '12 at 14:25
  • @Alex You do not seem to have realized that the `404 error` must be raised when "[_The server has not found anything matching the Request-URI_](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5)" and [the query](http://tools.ietf.org/html/rfc3986#section-3.4) (`?id=44`) is an integral part of the URI. For the `401`, "[_If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials._](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2)". – Pascal Qyy Jul 12 '12 at 15:18
  • @PascalQyy it should return 2xx even if the result isn't found because the file itself (resource) exists regardless of what the query says. It doesn't matter if the returned result is empty or not. In REST practice, if you have this URI like this "www.domain.com/index/id/foo" then the 4xx code would be appropriate if it couldn't find the result (resource). – netrox Dec 20 '12 at 22:43
  • The file is not the resource in this case, it is a script who is asked for looking for the resource in relation of the query string. if you read the [RFC2396](http://www.ietf.org/rfc/rfc2396.txt), you can see that the query string is part of the URI to the resource: `://?`. If the script can't find the resource asked in the query, so, it's a 4xx – Pascal Qyy Dec 27 '12 at 13:44