Sending info with a HTTP redirect that the browser should send to the redirected location?

Is this possible.. for example, imagine I respond to a request with a 302 (or 303), and I inform the browser to do a request to a given location.. is there a header that I can send with the HTTP 302, so that the subsequent request from the browser would include that header?

I know I could do this with the location header, as in redirect and specify the information in the url as a query string.. but I'm wondering if there is a better way.. it seems that it should be a legit scenario..

'Content has moved, go here .. oh and you'll want to take this with you to give to the redirect location'

I'm guessing a big fat no!

Thanks in advance.

Edit

The reason for this is in respect to PRG patterns, where you have a GET url and POST url, given that you post data and it isn't acceptable, the server redirects you to the GET, and does some 'magic' in order to 'send data' to that GET, using most often session state to store a variable.

However this can breakdown in scenarios where many of these PRG requests are happening, granted this isn't a common scenario and generally nobody need worry about this.. but if you do- you'll need a way to identify the requests, this can be done with query string parameters send in the 302.. so that a specific entry can be put in session state according to that request.

The question was regarding trying to remove the 'request key' from the url, and making it more implicit.. cookies 'appear' to work, but they only make the window for screw ups smaller.

It would be great to say when you go the 'location' i've specified, send these parameters.

Edit

Just to note, I'm not trying to get the browser to send arbitrary headers to the location, but if there is ANY headers designed to hint the context of the request (like the querystring parameters could).

tvanfosson, yes I understand a redirect doesn't contain data, and any query parameters are just that.. parameters that need to be understood.. however, specifically what I wanted to know was if it was possible to send those parameters outside of the querystring.

meandmycode 2009-06-07 14:10:44

Cookies for example, what if I sent a cookie that was removed by the receiver (the redirects are relative), would it be realistic to say that with multiple of these types of redirects happening at once, that the cookie send back from the request is send only with the subsequent request, and not mixed up with other requests (on the same machine (ie, imagine i hit the same url that redirects me at the exact same instance))?

meandmycode 2009-06-07 14:16:20

If the redirect and the target page are on the same hostname, then yes, a cookie sent by the redirect should be received by the client and sent back to the destination page. So yes, you can set a cookie with a redirect and have that cookie communicated forward. However, cookies of course cannot work cross-domain, so for a cross-domain redirect the only want of sending information forward is to put it in the URL itself, ie on the query string.

thomasrutter 2009-06-07 15:33:33

It is plausible that a browser could have a race condition where if the same cookie from the same domain was set in another tab/window at the precise moment this window is redirecting, it could send the other cookie instead. It's also plausible that some clients/browsers will reject cookies.

thomasrutter 2009-06-07 15:36:55

Thats fair, I wasn't so much after the browser sending arbitrary headers, but wondered if there was 'A' header that I could get it to send.. for example I can get the browser to send query string parameters to that url (if it doesn't go there that doesnt matter).. so why not be able to send other parameters that just aren't in the URL..

meandmycode 2009-06-07 14:23:45

That would cause security vulnerabilities. Just think of session fixation where the attacker tries to get the victim to use a specific session. He could then just say “set this session cookie with that session id”.

Gumbo 2009-06-07 14:45:04

I'm not sure I believe that argument, its the same as querystring parameters.. if your site is using them as session identifiers then thats bad.. this is purely about trying to redirect a client back PRG style, but with context about the 'id' of the original request.. in my scenario the key exists purely to identify the request instance per user.. so that if in the event of multiple posts to the form at once occured, the redirects are identifiable.. using session state is unreliable in this form.. i can do this today using query string parameters, but i really dislike using them for this..

meandmycode 2009-06-07 14:55:47

Additionally I've toyed with the cookie version, where a cookie is set in the 302, and thus sent with the subsequent request.. this 'appears' to work, when running load tests that are doing around 100 of these requests a second.. the browser so far ALWAYS does the redirected request immediately after the 302.. im sure theres no guarentees in the browsers, and that this is just due to the fast path of which this process runs through..

meandmycode 2009-06-07 14:59:03

ansaurus

tags:

views:

answers:

Sending info with a HTTP redirect that the browser should send to the redirected location?

related questions