453069 - When reloading after a 303 redirect, Firefox makes another POST request

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P5)

Description

[Torsten Bronger]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

After Firefox has made a POST request on a certain URL, an I reload, it makes another POST request (after I confirmed in the dialog box that this is what I want), which is correct behaviour.

However, if I keep the Firefox open and modify the server software so that it makes now a 303 redirect, FF follows the redirect, but further re-loads still make POST requests.

If the very first POST request resulted in a 303 redirect to *another* resource, further re-loads would make GET requests.

I *think* that this is heuristics to tackle the problem that a 302 redirect is handled by most browser non-conformant with the standard.  While this is sensible for 302, it is not for 303.  303 clearly says that the new resource should be fetched with GET.


Reproducible: Always

Comment 1

[You can call me Mark]

Another, related, but more interesting case:

Page A contains an iframe with a form, and a control that submits the form within the iframe. If page A is reloaded after the form has been submitted, and receives a 302 redirect to page B that has an unrelated iframe, Firefox submits the form within the iframe in page A, displays page B BUT INCLUDES THE IFRAME FROM PAGE A even though it's not in Page B's HTML at all!

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to Comment #1)
> Another, related, but more interesting case:

Probably Bug 279048.
(1) See Bug 279048 Comment #2, and skip to Bug 279048 Comment #53.
    See also bugs DUP'ed to Bug 279048.
   (No need to read comment three thru comment fifty-two of Bug 279048.       )
   (Comment three thru comment fifty-two is a my fight, mainly due to my lack )
   (of sufficient knowledge on "history", to find a way to avoid final load   )
   (by "history" upon "Reload" explained by comment two, if Web designer wants)
   (IFRAME's URL which is set by his JavaScript code instead of URL by history)

(In reply to Comment #0)

Fx's behaviour upon FORM POST depends on response to POST.
  - Fx's RFC-non-compliant behavior when 301/302 really exists.
  - "Redirect to same URL by 301/302/303" is not defined by RFC.
And, because FORM POST and Reload is involved, FORM history has relation.
So "what URL is loaded for form/how loaded by Reload" depends on response code and Fx's action when the response code.
Further, because "history" has relation, similar thing on IFRAME is applicable to FORM.
Please see above (1) and (2)/(3) below.

At least Next 6 cases should be cared.
(Case-1-A) 301 : POST to URL1 -> 301/Location=URL2(different URL)
  Sorry but I don't know Fx's behaviour when Case-1-A.
(Case-1-B) 301 : POST to URL1 -> 301/Location=URL1(same URL)
  What is client's correct behaviour?
(Case-2-A) 302 : POST to URL1 -> 302/Location=URL2(different URL)
  According to your Comment #0 and Bug 462097,
  Fx confuses "302 for POST" with "303 for POST" when Case-2-A.
(Case-2-B) 302 : POST to URL1 -> 302/Location=URL1(same URL)
  What is client's correct behaviour?
(Case-3-A) 303 : POST to URL1 -> 303/Location=URL2(different URL)
  According to your Comment #0, I think Fx behaves correctly when Case-3-A.
(Case-3-B) 303 : POST to URL1 -> 303/Location=URL1(same URL)
  What is client's correct behaviour?

I can say nothing about Case-1-B/2-B/3-B, because "redirect to SAME URL with 301/302/303" is not defined by RFC.
What is client's correct behaviour when "redirect to SAME URL"? Do you know?

------------------------------------------------------

(2) Copy of Bug 462097 Comment #9 - Fx's 301/302 handling
> Firefox seems to be one of "most user agents" in RFC 2616.
>  (for 302) most user agents react to a 302 response as described here for 303
> Firefox may be one of "some existing HTTP/1.0 user agents" in RFC 2616.
>  (for 301) some existing HTTP/1.0 user agents will erroneously change it into a GET request.

(3) Copy of Bug 462097 Comment #9 - 301/302/303 related part of RFC 26216
> RFC 2616(HTTP 1.1) says as follows.
> http://www.faqs.org/rfcs/rfc2616.html
>(snip)
> 10.3.2 301 Moved Permanently
>(snip)
>    If the 301 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.
>       Note: When automatically redirecting a POST request after
>       receiving a 301 status code, some existing HTTP/1.0 user agents
>       will erroneously change it into a GET request.
>
> 10.3.3 302 Found
>(snip)
>    If the 302 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user, since this might
>    change the conditions under which the request was issued.
>       Note: RFC 1945 and RFC 2068 specify that the client is not allowed
>       to change the method on the redirected request.  However, most
>       existing user agent implementations treat 302 as if it were a 303
>       response, performing a GET on the Location field-value regardless
>       of the original request method. The status codes 303 and 307 have
>       been added for servers that wish to make unambiguously clear which
>       kind of reaction is expected of the client.
>
> 10.3.4 303 See Other
>    The response to the request can be found under a different URI and
>    SHOULD be retrieved using a GET method on that resource. This method
>    exists primarily to allow the output of a POST-activated script to
>    redirect the user agent to a selected resource. The new URI is not a
>    substitute reference for the originally requested resource. The 303
>    response MUST NOT be cached, but the response to the second
>    (redirected) request might be cacheable.
>(snip)
>       Note: Many pre-HTTP/1.1 user agents do not understand the 303
>       status. When interoperability with such clients is a concern, the
>       302 status code may be used instead, since most user agents react
>       to a 302 response as described here for 303.
>(section for 307 is omitted)

Comment 3

[Bjarne (:bjarne)]

Is this still an issue? Maybe caused by the same issue as in bug #618835?

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.