[gcs-pcs-list] (possible) issue: what to do for redirects?

[Xiaoming Liu]

Dan,

I have been a little hesitant about this and 406 issue, I wonder if we are 
getting too smart of dealing with http response code, for several 
reasons:

a) it's hard to get all correct.
b) it may distract implementation and other important topics (such as 
Eric's comments).
c) it makes implementation difficult.

Here I suggest we have a look atom publishing protocol's approach, see 
section 5.5 of atom publishing protocol 
(http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt)

5.5  Use of HTTP Response codes

    The Atom Protocol uses the response status codes defined in HTTP to
    indicate the success or failure of an operation.  Consult the HTTP
    specification [RFC2616] for detailed definitions of each status code.
    It is RECOMMENDED that entities contained within HTTP 4xx and 5xx
    responses include an explanation of the error using natural language.

I am prone to Atom's approach.

I would vote 0 for 406 issue.

xiaoming


On Fri, 3 Mar 2006, Daniel Chudnov wrote:

> I'm not sure if this is an unAPI issue or not.
>
> In OPA, requests for things like images in binary formats can be
> simply redirected to another site.  See the flickr links here for
> examples:
>
>  http://onebiglibrary.net/project/opa/opa-0.2-release-with-json-wrapper
>
> If you follow, for example, the flickr jpeg_Original format link, OPA
> will respond with 302 Found with the flickr URL in the Location: header,
> and clients (browsers, wget) will follow the Location header URL.  e.g.:
>
>    [dlc33 at sildin tmp]$ wget "http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original"
>    --12:30:45--  http://opa.onebiglibrary.net/?uri=http://flickr.com/photos/dchud/100544935/&format=jpeg_Original
>               => `index.html?uri=http:%2F%2Fflickr.com%2Fphotos%2Fdchud%2F100544935%2F&format=jpeg_Original'
>    Resolving opa.onebiglibrary.net... 207.210.245.105
>    Connecting to opa.onebiglibrary.net|207.210.245.105|:80... connected.
>    HTTP request sent, awaiting response... 302 Found
>    Location: http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg [following]
>    --12:30:50--  http://static.flickr.com/32/100544935_ac537ae9e5_o.jpg
>               => `100544935_ac537ae9e5_o.jpg'
>    Resolving static.flickr.com... 68.142.213.135
>    Connecting to static.flickr.com|68.142.213.135|:80... connected.
>    HTTP request sent, awaiting response... 200 OK
>    Length: 1,357,967 (1.3M) [image/jpeg]
>
>    100%[====================================>] 1,357,967    453.28K/s
>
>    12:30:53 (451.83 KB/s) - `100544935_ac537ae9e5_o.jpg' saved [1357967/1357967]
>
>    [dlc33 at sildin tmp]$ file 100544935_ac537ae9e5_o.jpg
>    100544935_ac537ae9e5_o.jpg: JPEG image data, EXIF standard 2.2
>
>
> At first, OPA was returning 301 Moved Permanently but that didn't
> seem right as it hadn't "moved" at all.  302 Found seemed better.
>
> Admittedly, OPA is a weird application, seeing as it's a proxy, but
> it still raises the questions:
>
> - Is the redirection response within the scope of unAPI?
>   - If so, should we standardize the suggested HTTP status code(s)?
>     - If so, is 302 Found correct?
>
> - Is it wrong for OPA to use a redirect here?  i.e. would it be more
>   appropriate for OPA (as an unAPI service) to fetch the remote data
>   itself, and return *that* to the user directly, with the correct
>   content-type and a 200 code?
>
> This one is hurting my brain, I have no idea what the answers are.
>
>  -Dan
>
>
>

-- 
Xiaoming