Jump to content

HTTPRange-14: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Danstoner (talk | contribs)
m typo
History: wikilinks
 
(5 intermediate revisions by 4 users not shown)
Line 3: Line 3:
== History ==
== 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 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 (protocol)|Kermit]] had been around since 1981, more than ten years prior to the development of HTML).
The [[HTTP protocol]] was originally designed to transfer information objects, specifically [[Hypertext]] such as [[HTML]]. The GET request was issued by a client to retrieve data at a particular [[URL]]. Retrieving non-HTML information objects (images, [[Adobe Flash Player|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.


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.
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.
Line 9: Line 9:
== Use of # ==
== Use of # ==


URIs of real world things can be limited to 'hash URIs', that is URIs containing a [[fragment identifier]]. These URIs cannot be directly deferenced via HTTP so the protocol does not need to worry about the conflict. In this approach a URI not ending in a hash is understood to refer to a document, whereas the same URI with a '#' appended can refer to an abstract concept.<ref>http://dannyayers.com/2011/06/15/httpRange-14-Reflux</ref>
URIs of real world things can be limited to 'hash URIs', that is URIs containing a [[fragment identifier]]. These URIs cannot be directly deferenced via HTTP so the protocol does not need to worry about the conflict. In this approach a URI not ending in a hash is understood to refer to a document, whereas the same URI with a '#' appended can refer to an abstract concept.<ref>{{Cite web |url=http://dannyayers.com/2011/06/15/httpRange-14-Reflux |title=Danny on : HttpRange-14 Reflux |access-date=2013-06-07 |archive-url=https://web.archive.org/web/20120726101808/http://dannyayers.com/2011/06/15/httpRange-14-Reflux |archive-date=2012-07-26 |url-status=dead }}</ref>


== Use of HTTP Status Code 303 See Other ==
== Use of HTTP Status Code 303 See Other ==


The [[List of HTTP status codes|HTTP Status Code]] 303 See Other is to be interpreted as follows:<ref>{{cite web|url=http://tools.ietf.org/html/rfc7231#section-6.4.4 |title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |publisher=ietf.org |date= |accessdate=2013-07-26}}</ref>
The [[List of HTTP status codes|HTTP Status Code]] 303 See Other is to be interpreted as follows:<ref>{{cite journal|url=http://tools.ietf.org/html/rfc7231#section-6.4.4 |title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |year=2014 |publisher=ietf.org |doi=10.17487/RFC7231 |s2cid=14399078 |accessdate=2013-07-26|editor-last1=Fielding |editor-last2=Reschke |editor-first1=R |editor-first2=J }}</ref>
: A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.
: A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.
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<ref name="blog2">{{cite web|url=http://www.jenitennison.com/blog/node/170 |title=Using "Punning" to Answer httpRange-14 &#124; Jeni's Musings |publisher=Jenitennison.com |date= |accessdate=2013-06-04}}</ref> This is recommended as [[good practice]] by the W3C August 2007 draft.<ref name="tag">{{cite web|url=http://www.w3.org/2001/tag/doc/httpRange-14/2007-08-31/HttpRange-14.html |title=Dereferencing HTTP URIs |publisher=W3.org |date= |accessdate=2013-06-04}}</ref>
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.<ref name="blog2">{{cite web|url=http://www.jenitennison.com/blog/node/170 |title=Using "Punning" to Answer httpRange-14 &#124; Jeni's Musings |publisher=Jenitennison.com |date= |accessdate=2013-06-04}}</ref> This is recommended as [[good practice]] by the W3C August 2007 draft.<ref name="tag">{{cite web|url=http://www.w3.org/2001/tag/doc/httpRange-14/2007-08-31/HttpRange-14.html |title=Dereferencing HTTP URIs |publisher=W3.org |date= |accessdate=2013-06-04}}</ref>


== Resolution ==
== Resolution ==

Latest revision as of 19:52, 18 December 2023

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

[edit]

The HTTP protocol was originally designed to transfer information objects, specifically Hypertext such as HTML. The GET request was issued by a client to 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.

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 #

[edit]

URIs of real world things can be limited to 'hash URIs', that is URIs containing a fragment identifier. These URIs cannot be directly deferenced via HTTP so the protocol does not need to worry about the conflict. In this approach a URI not ending in a hash is understood to refer to a document, whereas the same URI with a '#' appended can refer to an abstract concept.[3]

Use of HTTP Status Code 303 See Other

[edit]

The HTTP Status Code 303 See Other is to be interpreted as follows:[4]

A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.

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] This is recommended as good practice by the W3C August 2007 draft.[6]

Resolution

[edit]

The W3C's Cool URIs for the Semantic Web document[7] recommends using one or other of these two methods, depending on the requirements of the project.

Implications

[edit]

The impact of the issue (more correctly the impact of confusion around the issue) is greatest in semantic web communities whose models involve large numbers of abstract concepts which cannot be serialised, such as the FRBR community.[8]

Further reading

[edit]

References

[edit]
  1. ^ "ISSUE-14: What is the range of the HTTP dereference function? - Technical Architecture Group Tracker". W3.org. Retrieved 2013-06-04.
  2. ^ "HttpRange14Webography - W3C Wiki". W3.org. Retrieved 2013-06-04.
  3. ^ "Danny on : HttpRange-14 Reflux". Archived from the original on 2012-07-26. Retrieved 2013-06-07.
  4. ^ Fielding, R; Reschke, J, eds. (2014). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". ietf.org. doi:10.17487/RFC7231. S2CID 14399078. Retrieved 2013-07-26. {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ "Using "Punning" to Answer httpRange-14 | Jeni's Musings". Jenitennison.com. Retrieved 2013-06-04.
  6. ^ "Dereferencing HTTP URIs". W3.org. Retrieved 2013-06-04.
  7. ^ "Cool URIs for the Semantic Web". W3.org. Retrieved 2013-06-04.
  8. ^ "eFoundations: httpRange-14, Cool URIs & FRBR". Efoundations.typepad.com. 2009-02-05. Retrieved 2014-07-03.