Re: HTTP method+status code combos and their (http) meaning.

Nathan wrote:
> The same mail in plain text http://webr3.org/http-combinations.txt - 

Some mini findings, things I'm sure about after analysing HTTP closely.

1: It is impossible to tell, via HTTP, whether at a given instant, a 
resource has one, or many, representations - thus it is impossible to 
say "the representation", only "a representation". That is to say, by 
looking at an HTTP request/response pair, or even a set of them, it's 
impossible to prove that a resource has a single representation at one 
time. (as in, an HTTP URI never identifies a representation, even at a 
single instant, HTTP does not provide a way to "say" that).

2: It is impossible to tell, via HTTP, if a resource has never existed 
(yet), the closest you can ever get is that is the unknown state (404 
for instance) or yes there was a resource, but it's gone now (410!)

3: The lifetime of a resource, the number of states a resource has 
had, and the times at which each state was changed, is impossible to 
determine by looking at HTTP messages, you cannot tell that resource X 
was created at time t1, changed to state n+1 at t2, n+3 at t3 and then 
reached it's final state (gone) at time t4.

4: It is impossible to tell if two HTTP resources are equal, or 
provably assert this, for two resources to be the same, they would 
have to have identical properties, which include interfaces, messages 
sent forwards and backwards, state changes via HTTP and other server 
defined methods (temporal, randomness, the temperature in a room) and 
so forth. The best you can assert (but cannot determine via HTTP 
message data) is that two resources share the same purpose.

example of 3 & 4:
One of the websites I manage, uses a publishing system to create 
static files, and serve them via two UI servers, both servers have the 
same specs, the same os same file system layouts on the same make and 
model of hard disks, the same versions of all software, they are 
effectively clones - the files are also "the same", and accessed via 
the same URIs (round robin dns), however, the ETags and Last-Modified 
differ on each server, and even if I synchronised these headers, and 
all headers, the fact would remain that yesterday i restarted one 
server and not the other, that for a second when the resources were 
created, one was there and the other was not; that if you got all the 
requests and response from each server, they would be a different set, 
and the resources /would/ be different - because, they are different. 
Same purpose yes, same things, no.

5: (obvious) HTTP is a messaging protocol, it deals with addresses, 
not names, thus when an GET results in a 301 Moved Permanently it 
means "moved to a new address" (just as humans do with buildings and 
mail redirects), not "moved to a new name" (which makes no sense), or 
"also known as" (which would be temporally invalid).

At this moment, that's the most I can conclude and be 100% sure about, 
there's a lot more, but I don't want to say it until I can prove it to 
be true.

Roughly, I'm quite sure that even the term "representation of" doesn't 
hold, and can only hold in very very specific circumstances, namely 
when the term "resource" is given a fixed meaning of "a file on the 
file system" and the set of HTTP methods and messages is constrained 
to a subset that allows this, precluding negotiation of all kinds, the 
POST method, and any kind of "dynamic" anything. I'm also quickly 
coming to the conclusion that thinking of a response message as 
anything other than just that, is dangerous and leads to incorrect 
statements being made, for instance it's impossible to prove that this 
holds:

   <http://example.org/foo.html> media:type "text/html" .

because there /may/ be another representation sitting there that you 
didn't GET (various other reasons including auth by IP, cookie, accept 
headers, temporal/random negotiation, all kinds of things), and thus, 
one should only be making statements like this about the message 
returned, by the server, in response to a certain request.

Will get there, and follow on later in some form..

Best,

Nathan

Received on Monday, 24 January 2011 16:15:31 UTC