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

[Mike Rylander]

On 3/3/06, Daniel Chudnov <daniel.chudnov at yale.edu> 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?

unAPI is fibbing a little about the direct response type in the
<formats>, but if the ultimate endpoint is what the <format> said then
I think it's OK.

>    - If so, should we standardize the suggested HTTP status code(s)?

I think HTTP does a good job of that, personally.  If the item used to
live at the URL that unAPI pointed you at, but some other system is
actually responsible for actually producing/delivering the content and
it really did move, I think a 301 would be correct.

>      - If so, is 302 Found correct?

For your case (and mine;  my "opac" format which also uses a 302 to
send you to the right place), I vote yes.  If working code wins, and
we both have idependently implemented similar redirect schemes, then
there's the pudding full of proof.  :)

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

It seems to me that this would put unduly heavy requirements on the
unAPI server.  If we're depending on HTTP response codes to figure out
what's going on, we should depend on them to get us to the endpoint as
well ... IMHO :)

> This one is hurting my brain, I have no idea what the answers are.
>
>   -Dan
>
>
> --
> Daniel Chudnov
> Yale Center for Medical Informatics
> (203) 737-5789
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
>


--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org