Re: 204 No Content for a resource which is known but has no representation yet?

I like "rule of law", and the RFC 2616 says for 204

   "The server has fulfilled the request but does not need to return an
   entity-body, and might want to return updated metainformation."

If that fits your use case, use it, but it sounds like it doesn't,
since the server has *not* fulfilled the GET request - to do that it
would have to deliver a "representation" or a redirection, and it has
not.

If you don't want to create a page to base a # URI on or for a 303 to
redirect to, how about using a data: URI as the Location: ?  E.g. a
303 with Location:
data:,This%20resource%20has%20yet%20to%20be%20specified . If the
browsers don't support data: in Location:, they should - file a bug
report. You could even use a # URI and a 307 with Location:
data:text/html,<div%20id="foo">...</div>#foo  ... I don't know whether
I'm kidding or not ...

Regarding Subbu's 202 suggestion, it's very clever, but both it and
your 204 idea are incompatible with the httpRange-14 rule (endorsed by
the LOD world, IIUC) which says "if an "http" resource responds to a
GET request with a 2xx response, then the resource identified by that
URI is an information resource".  [This is very badly expressed -
what's meant is "if an HTTP server responds to a GET request" and so
on - but not difficult to repair.]

As an aside, I am curious to know why you want to use non-# URIs and
303, rather than # URIs.

If you're thinking of trying to drum up support for some off-label use
of the HTTP protocol, good luck. After five years the status of 303 is
still shaky, in spite of some high-profile support.

Jonathan

On Sun, Mar 14, 2010 at 1:17 PM, Nathan <nathan@webr3.org> wrote:
> Here is the full problem and solution I'd like to use:
>
> I'm stuck with Linked Data, which is tied to the http scheme and
> has a constraint that the http scheme URIs we use as identifiers must be
> dereferenced via http. The only way is forwards from what I can tell.
>
> As I see it (within the http scheme of uris), a resource is a conceptual
> map to anything; that anything either has a representation that can be
> sent via http or does not. In the case where it does not, the concept
> maps to an "empty set" of representations.
>
> With regards the above this calls for the usage of only 4 http status
> codes (from what I can tell, certainly I could get by with them), as
> follows:
>
> 204 No Content (in the case of GET), resource which maps to an empty set
> / does not have a representation of its own that can be transferred by
> the server over HTTP and no other resource is known which describes the
> requested resource.
>
> 301 Moved Permanently, The requested resource has been assigned a new
> permanent URI and any future references to this resource SHOULD use one
> of the returned URIs.  Clients with link editing capabilities ought to
> automatically re-link references to the request-target to one or more of
> the new references returned by the server
>
> 303 See Other, indicates that the requested resource does not have a
> representation of its own that can be transferred by the server over
> HTTP, and additionally specifies a resource which may provide
> information about the requested resource.
>
> 410 Gone, The requested resource is no longer available at the server
> and no forwarding address is known.  This condition is expected to be
> considered permanent.  Clients with link editing capabilities SHOULD
> delete references to the request-target after user approval.
>
> All of these codes are there already and do the job perfectly (imho),
> and the others do not matter with regards linked data since we aren't
> dealing with things which have a representation / entity.
>
> additionally, it may be worth noting that I'm not doing any "content
> negotiation" with a 303 See Other, rather I'm doing any required content
> negotiation on the second resource, the one pointed do by the Location
> header; personally I find it cleaner to keep a distinction between
> resources with a representation and those without, and view content
> negotiation in response to a request on a resource with no
> representation as a cross cutting concern, hence dually seperated.
>
> I am aware this would be a refinement to the resolution of httpRange-14,
> have done vast amounts of research on this (more than I expected) and in
> reality I'm just a developer who is blocked on a project and I just need
> some kind person from IETF/W3C (pref TAG) to say this doesn't conflict
> with the architecture of the world wide web or conflict with HTTP/REST.
>
> Which means, somebody like Larry, or Roy, Tim etc; or even Jonathan Rees
> as this very much ties in with the work on
> http://www.w3.org/2001/tag/awwsw/http-semantics-report.html
>
> I'm really stuck here, and it's having real effects on my daily
> life at home - I need to get this project finished and the above is the
> only realistic solution after all my hunting; I'm trying so hard to do
> things by the book  :(
>
> Many Regards & most sincerely,
>
> Nathan
>
> Nathan wrote:
>> Hi All,
>>
>> Can I use a 204 No Content to indicate that a resource is known but
>> currently does not have a representation (or another resource which
>> describes it)?
>>
>> example:
>> I have a resource which is a conceptual map to "me"; I have assigned a
>> URI to that resource, am in the process of creating a document which
>> describes me, and when I am done I will 303 See Other to the document
>> from the resource which is a conceptual map to "me".
>>
>> In the interim what status code can I use to say that the resource is
>> known, does not have a representation of its own that can be transferred
>> by the server over HTTP, another resource is not know that is
>> descriptive of said resource & the resource identifier is not to be used
>> for anything else.
>>
>> I've fully checked through all status codes, including the 4xx's but
>> can't find any to use, and 204 No Content seems to fit the best as far
>> as I can tell.
>>
>> Many Thanks,
>>
>> Nathan
>>
>>
>>
>
>
>

Received on Sunday, 14 March 2010 21:20:38 UTC