W3C home > Mailing lists > Public > www-tag@w3.org > June 2005

Re: [httpRange-14] Resolved

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 20 Jun 2005 23:19:11 -0400
To: Jan Algermissen <jalgermissen@topicmapping.com>
Cc: W3C TAG <www-tag@w3.org>
Message-ID: <OFD73F8AD1.C5DB67C5-ON85257026.006BB6EA-85257027.00123D4D@lotus.com>

Jan Algermissen writes:

> Understood. OTH...how do I determine the GET
> response code of a fragment identifier URI (given
> that the server never sees the fragment)? 

Presuming you mean the response code to an HTTP protocol GET, the answer 
is "you don't."  As you've noted, the Request-URI transmitted using HTTP 
does not include the fragment identifier.  In that sense, the GET 
operation is not defined by HTTP on URIs that have frag. ids.

In general, the semantics of frag. ids are determined by the media type(s) 
of the representation(s) returned for the URI that is transmitted (I.e. 
the one without the frag. id.)  So, it would be possible in principle for 
the specification for such a media type to define an operation in the 
spirit of GET, and in turn to define response codes for that operation.  I 
haven't seen such operation-oriented mechanisms defined for most widely 
deployed media types; in any case, such operations would not be HTTP 
GET's, and might or might not involve any additional network activity. 
Thus, in practice, there are no response codes for secondary resources. 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Tuesday, 21 June 2005 03:19:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:09 UTC