Re: Web architecture expertise

I have always understood that no headers can be sent to a 3rd party server along with a redirect: it’s up to the client to re-issue headers if they want.

When I use Apache’s redirect or mod_rewrite for PID requests that have important headers – perhaps a client has requested Turtle for a resource – I’ve had to either include query string arguments of a pseudo file extension to communicate this to the 3rd party server so:

GET /resource/x
Accept: text/turtle

HTTP/1.1 302 Found
Location: /new-resource/x.ttl

Or

Location: /new-resource/x?_format=text/turtle


I would love to know of a more elegant solution but I fear that carrying forward headers looks like it’s breaking stateless HTTP…

Nick



From: Rob Atkinson <robatkinson101@gmail.com>
Date: Friday, 31 May 2019 at 2:45 am
To: Philippe Le Hegaret <plh@w3.org>
Cc: "Svensson, Lars" <L.Svensson@dnb.de>, Nicholas Car <Nicholas.Car@csiro.au>, Dataset Exchange Working Group <public-dxwg-wg@w3.org>
Subject: Web architecture expertise

Hi Phillippe, and the broader DXWG group..

In the content negotiation by profile discussions we have come across a question we cannot answer easily, and maybe the web architecture experts at W3C can advise on, (given they will review anyway as far as i understand).

The matter concerns HTTP redirection and role of headers...

https://github.com/w3c/dxwg/issues/603


if a redirection service is performing negotiation to a range of static resources, is it able to pass information via headers to the client (in practice)

a client that looks at the redirections can obviously gather the information, but most clients will use standard libraries like python urllib, java HttpUrlConnection - is there a expected behaviour tested for such implementations?

we need some advice as to how to proceed - either a better approach - or if there are good connections with the authors of such libraries we might be able to start a conversation with to get implementation support?

Regards
Rob Atkinson

Received on Thursday, 6 June 2019 19:28:43 UTC