HTTPRange-14
 | This article, HTTPRange-14, has recently been created via the Articles for creation process. Please check to see if the reviewer has accidentally left this template after accepting the draft and take appropriate action as necessary.
Reviewer tools: Inform author |
HttpRange-14 is a long-running logical conundrum or design problem in the semantic web. The problem arises because when HTTP is extended from referring only to documents to talking about real-world things (planets, flowers, emotions, Platonic forms, etc) the domain of HTTP GET becomes undefined.[1][2]
History
The HTTP protocol was originally designed to transfer information objects, specifically Hypertext such as HTML. The GET request was issued by a client to the retrieve data at a particular URL. Retrieving non-HTML information objects (images, flash files, CSS files, streaming video, etc) was not a problem, since all of these could be streamed across the network using standard approaches developed by earlier protocols (Kermit had been around since 1981, more than ten years prior to the development of HTML).
The semantic web was invented, spearheaded by the W3C and Tim Berners-Lee, which used URLs to refer to real world things (planets, flowers, emotions, Platonic forms, etc) which could not be reduced to network streams. The question of what web servers should do when asked for one of these things arose.
Use of #
URIs of real world things can be limit to 'hash URIs', that is URIs containing a fragment identifier. These URIs cannot by directly deferenced via HTTP so the protocol does not need to whole about the conflict. This is recommended by the W3C's Cool URIs for the Semantic Web document.[3]
Use of HTTP Status Code 303 See Other
The HTTP Status Code 303 See Other is defined as:[4]
- The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
By sending a 303 when asked for a non-information resource and redirecting to an information resource about the non-information resource, the server answers the requesters information need without having to supply the actual thing[5][6] This is recommended as good practice by the W3C August 2007 draft.[7]
Resolution
There is no official resolution the the HTTPRange-14 problem. There is a Dereferencing HTTP URIs document from the W3C, but the latest version is empty,[8] an earlier version contains recommendations.[7]
Further reading
References
- ^ "ISSUE-14: What is the range of the HTTP dereference function? - Technical Architecture Group Tracker". W3.org. Retrieved 2013-06-04.
- ^ "HttpRange14Webography - W3C Wiki". W3.org. Retrieved 2013-06-04.
- ^ "Cool URIs for the Semantic Web". W3.org. Retrieved 2013-06-04.
- ^ "HTTP/1.1: Status Code Definitions". W3.org. Retrieved 2013-06-04.
- ^ "The web's identity crisis and httpRange-14 | Larsblog". Garshol.priv.no. 2007-10-08. Retrieved 2013-06-04.
- ^ "Using "Punning" to Answer httpRange-14 | Jeni's Musings". Jenitennison.com. Retrieved 2013-06-04.
- ^ a b "Dereferencing HTTP URIs". W3.org. Retrieved 2013-06-04.
- ^ "Dereferencing HTTP URIs". W3.org. Retrieved 2013-06-04.