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

Hi Jonathan,

Thanks for your input :) I am going to question some of what you've
written but it's meant with the best intentions possible, and obviously,
no disrespect at all.

Jonathan Rees wrote:
> 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.

I'm swapping to HTTPbis quotes, because if we go by 2616 then the usage
of 303 should be questioned too.

HTTPbis says of GET:
  "The GET method means retrieve whatever information (in the form of an
   entity) is identified by the request-target."

The GET request in this case retrieves whatever information is
identified by the request-target, which happens to be an empty set; thus
an empty entity, thus "No Content".

With regards 204, the request has been fulfilled and does not need to
return an entity body (because it's an empty set).

In reality I would love to see an addition to 204 in HTTPbis similar to
the 303 addition, something along the lines of:
   "A 303 response to a GET request indicates that the requested
    resource does not have a representation of its own that can be
    transferred by the server over HTTP, and further does not know
    of any resource that is descriptive of the resource"

but also, really don't want to push my luck :p

> 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 ...

Not sure what to say to that, something in me thinks that if such
obscure things are being suggested as a fix, then it's more of a hack
and the real issue needs addressed (with no disrespect) - It's an idea,
but I also don't want to assume that the client would be able to handle
the data scheme, or the chosen media-type for the message, and a few
other reasons I don't really want to go in to unless this is seriously
being considered :) I am quite a fan of the data scheme though, perhaps
not in this specific use case though.. more for small in line images etc
to save a few http requests.

> 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 for 202, I agree clever, but its purpose is to allow a server to
accept a request for some other process, and that isn't the case;
moreover the reason I suggested 204 and not 202 was because the term
used "Accepted" really doesn't say what I want to say, and what I want
to say is "No Content".

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

Multiple reasons to be honest, and they are going to be tricky to word
correctly...

A resource is a conceptual map to anything; a URI identifies a resource.
If I have a resource which is a conceptual map to a non-virtual Object
(real world object, thing, me, whatever) and a second resource which is
a conceptual map to a description (which can be passed via http) of the
first resource; then I have 2 fixed resources. 2 resources need 2
identifiers, thus 2 URIs.

http scheme URIs have a duality in that they are an identifier and a
locator, an http scheme uri with a fragment indicates that the resource
is a secondary resource, and furthermore that it is a secondary resource
where the primary resource is a conceptual map to some representation
which has a media-type which supports fragments.

IMHO by using a fragment identifier (within the realms of linked data
and http) you are binding a resource to its description, and often
multiple resources to a single description; this is a cross cutting
concern and it needs separated.

example:
http://example.org/people#me  (me)
http://example.org/people#you (you)
http://example.org/people (description of me and you)
... some months later we refactor the descriptions to be ...
http://me.org/person/nathan (description of me)
http://you.org/person/jonathan (description of you)

To coin a phrase "303 your way out of that one"; throw conneg in to the
equation too and it gets even messier.

Further and far far more importantly, we have 2 references, 1 uri; and
thus 1 uri to identify two resources, but a uri only identifies one
resource - meaning you are me, and I am you :) actually.. you are me, I
am you, and we are both an http entity which (hopefully) describes our
siamese binary ass, I'll tell my (our) kids!

I would ask, why don't you do the following?
http://yoursite.org/content#about
http://yoursite.org/content#contact
http://yoursite.org/content#post-1
http://yoursite.org/content#post-2
http://yoursite.org/content#a-face-gif
http://yoursite.org/content#a-logo
http://yoursite.org/content#a-paper-you-wrote
http://yoursite.org/content#another-paper-you-wrote
http://yoursite.org/content#your-foaf

I firmly believe that everything is a resource and everything needs an
identifier, every representation is a thing which needs its own
identifier; and thus everything with a representation needs (at-least)
two identifiers, one for the conceptual map to that thing, and another
for the conceptual map to the representation.

If you create an html document on your computer and wish to describe it
you create a conceptual map in your mind to the html document; then
assign it a uri - if you email the html document, it's still the same
thing, if you upload it to a web server, it's still the same thing - and
at such a time if you wish to make it visible you'll need to give it a
second identifier (uri) one which is a conceptual map to the
representation of the html document as stored on your server, upload it
to another server and you need a third identifier which is a conceptual
map to that representation on that server. All the while the html
document is still only 1 resource.

Add in a few serializations of an rdf description to boot, and then try
using fragment identifiers (+ before mentioning rdfa, quickly change
html to gif in the above example).

These, along with a few more reasons, are why I don't use #fragments for
"things" - i do however use fragments to describe things as they come in
to play very nicely here - but that's a different conversation :)

> 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.

well, I'm about as low profile as you can get, but thanks for the good
luck wish :)

> Jonathan

Many Regards,

Nathan

> 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 Monday, 15 March 2010 00:00:13 UTC