|
|
OAI-ORE |
> variant
although the language in section 1.3 is a little confusing, I
regardless, the AWWW abandons the "variant" vs. "representation"
200 + Content-Location == 301/302/303/307 + Location
even though we all understand that is what is actually happening.
its not that it is confusing -- that was my point that it makes
> variant
although the language in section 1.3 is a little confusing, I
regardless, the AWWW abandons the "variant" vs. "representation"
200 + Content-Location == 301/302/303/307 + Location
even though we all understand that is what is actually happening.
its not that it is confusing -- that was my point that it makes
> variant
although the language in section 1.3 is a little confusing, I
regardless, the AWWW abandons the "variant" vs. "representation"
200 + Content-Location == 301/302/303/307 + Location
even though we all understand that is what is actually happening.
its not that it is confusing -- that was my point that it makes
(and it actually happens a lot -- Apache has implemented a version
the 303 generalized content negotiation does remove the de facto
of course, none of this changes your other, more salient points.
> As far as I can tell, the terms "representation" and "variant" are
actually, the RFC makes a distinction: representations correspond
> interchangeable in HTTP.
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/
> html/rfc2616#section-1.3)
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
but that's just it -- I don't think RFC-2616 adequately *models* what
> designed to model it.
is happening. nowhere does it explicitly state that:
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
> As far as I can tell, the terms "representation" and "variant" are
actually, the RFC makes a distinction: representations correspond
> interchangeable in HTTP.
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/
> html/rfc2616#section-1.3)
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
but that's just it -- I don't think RFC-2616 adequately *models* what
> designed to model it.
is happening. nowhere does it explicitly state that:
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
> As far as I can tell, the terms "representation" and "variant" are
actually, the RFC makes a distinction: representations correspond
> interchangeable in HTTP.
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/
> html/rfc2616#section-1.3)
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
but that's just it -- I don't think RFC-2616 adequately *models* what
> designed to model it.
is happening. nowhere does it explicitly state that:
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
less transaction).
of RFC-2295 since forever (which defines that you only get a 300
response only if you explicitly ask for it with a Negotiate: request
header) -- its just that few people witness it. client send various
Accept.*: request headers and the server responds with the correct
Vary:, TCN: and Alternates: response headers and few people actually
witness it. I mention this only b/c there is a prevailing belief
that content negotiation doesn't happen a lot -- it happens, but
people just don't see it b/c the client is not redirected (i.e.,
the URL in the toolbar doesn't change)).
restriction of occuring on the same server. That is conventionally
you can only do things of the form: http://foo/a --> http://foo/a.html.
with AWWW 303 style CN you can do: http://foo/a --> http://bar/a.
but this flexibility does cost you an extra http transaction.
I just like to talk http. ;-)