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

From: Nathan <[email-masked]>
Date: Sun, 14 Mar 2010 00:38:17 +0000

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

---

From: Reto Bachmann-Gmür <[email-masked]>
Date: Sun, 14 Mar 2010 01:52:20 +0100

Hi Nathan

Returning 204 would be against the resultion of HttpRange-14 as a 2XX
response implies the identified resource is an information resource
and you are not.

So either return a 404, or return a 303 response pointing to a URI
that currently (as no representation is available) yields to a 404.

Cheers,
Reto

---

From: Nathan <[email-masked]>
Date: Sun, 14 Mar 2010 01:12:19 +0000

Thanks for getting back to me so quickly Reto,

> response implies the identified resource is an information resource

Well noted about httprange-14! However this could easily be an
information resource that is "coming soon", for example I am writing a
document that will be available at 'uri' next week.

> that currently (as no representation is available) yields to a 404.

303 to a resource which 404's sounds like it could work.. 404 I am keen
to avoid.

Can you use a 3xx without a Location header?

---

From: Nathan <[email-masked]>
Date: Sun, 14 Mar 2010 17:17:21 +0000

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

---

From: Subbu Allamaraju <[email-masked]>
Date: Sun, 14 Mar 2010 13:45:38 -0700

Since the action that the client asked for will not be complete at the time of returning the response and since the server can't guarantee (I am assuming this based on the description of the flow in the example below) that the request will be processed without an error, why not return a 202 in stead?

Subbu

---

From: Jonathan Rees <[email-masked]>
Date: Sun, 14 Mar 2010 17:19:57 -0400

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

---

From: Subbu Allamaraju <[email-masked]>
Date: Sun, 14 Mar 2010 15:45:56 -0700

> on - but not difficult to repair.]

My interpretation of Nathan's example is that the documentation creation starts in response to a write such as POST, in which 202 is valid. 202 on GET is goofy.

Subbu

---

From: Nathan <[email-masked]>
Date: Sun, 14 Mar 2010 23:58:58 +0000

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.

> would have to deliver a "representation" or a redirection, and it has

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

> data:text/html,<div%20id="foo">...</div>#foo  ... I don't know whether

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.

> 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

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 :)

> 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

---

From: Nathan <[email-masked]>
Date: Mon, 15 Mar 2010 00:02:54 +0000

>    "A 303 response to a GET request indicates that the requested

erm.. A 204 response to a GET request indicates that the requested

typo

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 14 Mar 2010 17:22:32 -0700

On Mar 14, 2010, at 10:17 AM, Nathan wrote:

> I'm stuck with Linked Data, which is tied to the http scheme

No, it isn't, unless you mean the data you happen to be using
is only identified by http scheme URIs.

> and
> dereferenced via http.

Are you making this up?  No known system that I am aware
of has that limitation.

> The only way is forwards from what I can tell.
> 

Not really, no.  HTTP provides an interface for interacting with
resources by way of making a request with a standard method upon
a request-target that is a URI (with various parts scattered about
for historical reasons).  HTTP provides that interface for URIs
of any scheme.  Naturally, the native "http" scheme is most popular
for this purpose because it maximizes the HTTP interface without
requiring additional name services beyond hostname resolution (DNS).

The GET method, when applied to any resource, means get me a
current representation of the identified resource.  HTTP doesn't
need to say how it is possible for the server to know or obtain
such a representation -- it simply does or does not do so.

> the server over HTTP and no other resource is known which describes the

No, 204 means no content is the reply.  It is never used with GET.
404 means there is no current representation (i.e., not found).

> information about the requested resource.

Yes, when used in response to GET.

> dealing with things which have a representation / entity.

Well, then you aren't using linked data.  I don't know what you
are doing, but it is almost certainly wrong to say that data has
no representation, and the whole point of linked data is to
link the data via representations.

> representation as a cross cutting concern, hence dually seperated.

Agreed.

> http://www.w3.org/2001/tag/awwsw/http-semantics-report.html

Good luck with that.  The semantics report postulates a theory
of existence for resources that simply does not matter to HTTP,
and hence will be irrelevant to any real system you might build
using HTTP aside from a closed-world graph theorem prover.

Even the REST notion of a discontinuous conceptual mapping function,
which says exactly the same thing as the "correspondences"
discussion in only four words, is merely an attempt to explain
reality to a formalist, not make a formal restriction on reality.

> only realistic solution after all my hunting; I'm trying so hard to do

Implement it first, using what works, and then tell the TAG
what the theory should be.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Nathan <[email-masked]>
Date: Mon, 15 Mar 2010 01:03:19 +0000

> Are you making this up?  No known system that I am aware

I think I worded it wrong, duly noted - I was referring to the case
where data is only identified using http scheme URIs and the assumption
that I should/must provide lookup (at this time) via dereferencing using
an http get, primarily because nobody else is talking about another way
of looking up those identifiers (that I am aware of).

> such a representation -- it simply does or does not do so.

noted and thanks for clarifying; I'd made that mental mistake of binding
HTTP to the http scheme.

> 404 means there is no current representation (i.e., not found).

that wipes out that option then! is there even such a thing as found but
with no description? i feel there is but now questioning. somebody else
suggested a 303 which resolves to a 404 - would that work?

> link the data via representations.

agreed, really I just want a way to "reserve" a resource/uri unambiguously.

> Chief Scientist, Day Software              <http://www.day.com/>

Thanks Roy, will try and get something working properly; facing many
challenges and hence all the feedback requests.

as a side note; does anybody have any suggestions for looking up data
with something like tdb uris? if there is a better way than just using
http scheme to dereference, even to be used in addition to http scheme
uri's, I'd be most interested - obviously keen not to have all the data
I ever produce bound to http scheme uri's only for looking up to get
more info etc.

Many Regards,

Nathan

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 15 Mar 2010 13:05:16 +0900

You say that there will be something there in about a week. What about 
just waiting a week? Then your problem will go away :-). Another 
alternative might be to put something very simple there now (e.g. an 
empty document) and update that later. The empty document (or a 303 to 
an empty document) seems to express quite well what the system currently 
can say about this URI.

Regards,    Martin.

On 2010/03/14 9:38, Nathan wrote:
> descriptive of said resource&  the resource identifier is not to be used
> for anything else.
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Nathan <[email-masked]>
Date: Mon, 15 Mar 2010 08:49:21 +0000

Hi Martin,

I'm actually having a full back track on my thought..

If a resource is anything that can be named, then I have it's name / can
describe what it is, so I should stop being lazy and at least give what
tiny bit of information I know (even if just the name).

The above may have been the solution I needed all along (gulp)

Regards,

Nathan

---

From: Tim Berners-Lee <[email-masked]>
Date: Mon, 15 Mar 2010 11:05:52 +0000

> The above may have been the solution I needed all along (gulp)

Sounds like an excellent idea.

<#foo> rdfs:comment "Information about this will be available shortly  --Nathan".

in N3 for example.

Tim