Open Bug 1013302 Opened 7 years ago Updated 7 years ago

400 Errors should not be stored in session history


(Core :: DOM: Navigation, defect)

29 Branch
Windows 8.1
Not set





(Reporter: wrobel.przemyslaw, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

I am developing an application with a form that validates itself. When the form does not pass validation we are returning the 400 Bad Request error. 

Actual results:

When I save the correct data (we correctly issue a 320 redirect then) and then the user hits the back button the firefox asks about sending again the POST with the incorrect (not validating) data.

Expected results:

According to sources like or
such a request should not be send again to the server: "The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications." - so browser should not store it in history.
It would not be elegant to use 404 in such situation since the url is actually valid - the same url but with the GET header present a user with the form.
QA Whiteboard: [bugday-20140526]
Component: Untriaged → Bookmarks & History
sounds more like document navigation than global history
Component: Bookmarks & History → Document Navigation
Product: Firefox → Core
We're not automatically repeating the request, which is what the RFC is talking about.  We're explicitly being asked by the user to repeat the request.

But more importantly, what exact behavior are you proposing for session history (which is what this is about; this isn't about global history) here?  What do other browsers do?  As far as I can tell, we're doing the only sane thing we _can_ do here, and it's what every browser does and what the web platform specs say to do.
Flags: needinfo?(wrobel.przemyslaw)
Summary: 400 Errors should not be stored in history → 400 Errors should not be stored in session history
I will check what happens in other browsers and let you know...

The RFC says the request should not be repeated without modification and this is excatly what is happening here - I agree that the users is asked for confirmation but still the request will always be sent without modification (or not sent at all) because the user will not be able to alter the data.
I thought the browser will behave the way it does with 3xx errors i.e. not to store it in the history.
Or perhaps there is another way to resolve my problem?
Flags: needinfo?(wrobel.przemyslaw)
There's a difference between "should not" and "must not".  There's also a difference between clients automatically deciding to repeat a request and a human explicitly instructing a client to do so.

> Or perhaps there is another way to resolve my problem?

I don't know, because you never clearly described your problem...
Oh, and 3xx responses are not errors.  And they _can_ get stored in session history sometimes (e.g. if the redirect fails).
You need to log in before you can comment on or make changes to this bug.