[wp-trac] [WordPress Trac] #13909: Redirect does not return a HTTP body

[WordPress Trac]

#13909: Redirect does not return a HTTP body
--------------------------+-------------------------------------------------
 Reporter:  hakre         |       Owner:                
     Type:  defect (bug)  |      Status:  new           
 Priority:  normal        |   Milestone:  Future Release
Component:  General       |     Version:  3.0           
 Severity:  normal        |    Keywords:  needs-patch   
--------------------------+-------------------------------------------------

Comment(by hakre):

 Replying to [comment:7 dd32]:
 > This will not fare well in its current state.
 >
 > Take a Plugin activation command for example, Current workflow is
 Request->Redirect(error occured)->Activate plugin->Redirect(final
 activated)->End of process -> Redirect occurs to the last url
 >
 > With this patch, Output will be generated after the first redirect,
 causing the 2nd redirect to fail (as headers will already be sent).

 Good point, I tested that now. It creates fatal errors because of
 redeclaration(functions and classes if the plugin defines those and which
 plugin does not, right?).

 But it reveals as well that plugin activation does not work with manual
 redirects. That might seem odd, but I'll add more details below.

 > For front end queries it may make sense to offer some form of
 redirection text, I'm not supporting it on the back end however, Its an
 extra level of complication which just isn't needed.

 It even ''should'' be added. I'll explain that below. But you're right, I
 put this on the agenda because of front end usage.

 >
 > A user disabling their redirection handling is bound to suffer because
 of their choices,

 Do not blame the user if you do not have a valid reason I tend to say. In
 this case, it's not the user to blame for and I will show that below.

 > Opera for example, generates a content near exact to that example HTML
 you provided transparently when it blocks a redirection.

 The generated page by Opera you write about - even I know it - I do not
 have it in 10.53 in my tests reg. this ticket. But that's something to
 discuss in the Opera forums and should not be the point here. As well as
 it shouldn't be the point to discuss how any specific browser is
 implementing redirects. That's web done wrong.

 > Its the browsers option to ignore Redirects, Its the browsers
 responsibility to handle that redirect..

 Instead of assuming stuff I suggest to talk about HTTP now. I made that
 error in the first place as well, but I'm willing to correct that now.

 ----

 So my apologies: I did not read the specification before implementing my
 version of the redirect. That's mainly because I approached this from the
 usability side, by a personal experience. And then I compared it to only
 google w/o taking a deeper look why google or apache might do it that way
 and not in another way. dd32 comments let me investigate that further. So
 this is where I am now:

 The standard this is based on is
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html HTTP 1.1 / RFC
 2616] (and somehow even HTTP 1.0 / RFC 1945 but I leave this out for the
 moment).

 The specification is pretty straight forward about redirects and what
 SHOULD/MUST/CAN a browser do on the various response codes. Generally
 spoken, wordpress can not take it for granted that a redirect is carried
 out in response of a GET request:

 >  The action required MAY be carried out by the user agent without
 interaction with the user
 (10.3 Redirection 3xx - RFC 2616)

 That is a [http://www.ietf.org/rfc/rfc2119.txt may]. And further for 302
 responses:

 > the entity of the response SHOULD contain a short hypertext note with a
 hyperlink to the new URI(s).
 (10.3.3 302 Found - RFC 2616)

 Note the ''should'' here.

 Therefore: A webapplication can not expect that a user-agent automatically
 redirect (because it's completely optional or "truly optional" as the RFCs
 specify it). So it makes sense to provide a short hypertext note with a
 hyperlink to the new URI in case of a 302 redirect. Otherwise the user is
 left alone.

 So what does that mean?

 a) The redirect like currently done in WP_Redirect does not reflect the
 SHOULD in HTTP 1.1 for 302 redirects properly.

 b) Same for my patch. I must update my patch to go conform with 302 etc. .

 c) Automatic redirects are truly optional on GET and a webapplication
 should deal properly with that if it aims for being conform with HTTP 1.1.

 That for a start. I'll update the patch and continue my read on the RFC to
 learn more. Maybe there is a solution by using propper status codes and
 this can be easily solved while gaining a better conformity with HTTP 1.1
 as well. I think especially "c)" is the hardest to deal with.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13909#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software