Yes, got the same "Confirm Form Resubmission" after all redirect codes (301/302/303)

Chrome: 25.0.1364.97 m
OS: Windows 7

but in version Chrome 24.0.1312.57 it wasnt.

This is happening in Mac OS version, too: 25.0.1364.99

Looks like we're also doing a repost, not just asking for confirmation.

Logic for the repost warning actually lives at the navigation controller level, which gets the information from webkit, rather than the network stack.  Adding relevant tags, and hoping issue sounds familiar to someone.

If needed, I can bisect to locate the regression.

Could you change the type back to a bug? This is far more severe than a polishing issue. It disrupts user-flows on websites and could lead to duplicate data submissions.

tomsommerdk:  Do you see the same behavior if the 303 redirects to a different URL?  What about for 302 redirects to the same URL?

I suspect this is related to the before and after URLs being the same, though it could actually be deliberate behavior.

From the RFC:  "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."

So if reloading is supposed to reload the originally requested resource, and the new URI is not a substitute reference for the requested resource, this behavior may make sense.

Since I don't see anything in WebKit to do this, though, I don't think this is the issue, but would be nice to confirm that.

„Do you see the same behavior if the 303 redirects to a different URL?“

It does not seem to be a problem as long there is *any* get variables even it is the same address. See http://demo.sperke.net/postredirect2.php (submit it multiple times)

„What about for 302 redirects to the same URL?“

Will lead to the same problems - 301 also.

„So if reloading is supposed to reload the originally requested resource, and the new URI is not a substitute reference for the requested resource, this behavior may make sense.“

Reloading of the form is still wrong. That's what 303 is supposed to do - replacing the form and present the result. By reloading the page, you should reload the last request and as seen in the network statistics this is a get request. 

postredirect2.php 205 bytes View Download

Thanks!  That confirms it's a bug.  Just wanted to be absolutely sure that was the issue.

Ahhhh, sorry sorry. First I uploaded the wrong file. The correct file is attached. Second the confirm dialog is still present even if the url changed. I tested on my linux laptop, that is still on Chromium 24, where this bug is not present.

In Chrome 25 (tested on Windows in VM) the confirm reload dialog appears with all redirections (301/302/303) and with the get parameter too (if the url has changed or not).

Attached file again due it was not uploaded after wrong captcha.

postredirect2.php 220 bytes View Download

[+creis, japhet]

Looks like the regression was between 172942 and 172978:  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=172942%3A172978

It seems most likely to me that the bug is related to changes in one or more of the following:  Reloads, caching, logic to prevent reloads in the case of matching URLs (Possibly with different fragments).

Most suspicious CLs in that timeframe:

http://src.chromium.org/viewvc/chrome?view=rev&revision=172951 by creis was a small change in reload behavior.  Doesn't look related to me, but could be.
http://src.chromium.org/viewvc/chrome?view=rev&revision=172953 was a WebKit roll, 137596:137615.  http://trac.webkit.org/log/?rev=137615&stop_rev=137597&verbose=on

Most suspicious WebKit changes:

137607 https://bugs.webkit.org/show_bug.cgi?id=49246 - "Route main resource loads through the memory cache."
137604 https://bugs.webkit.org/show_bug.cgi?id=104721 - "CachedResources should hang on to stripped fragment identifiers"

None of the other look as likely to be related.  CCing the authors of those CLs.

To clarify, that range came from bisecting chromium builds.

Hey Matt, so this was working before 172942? I'm asking because it sounds very similar to  bug 21245 , and that one has been open for a long time (unless at some point it was fixed without connection to that report). Do the repro steps from https://code.google.com/p/chromium/issues/detail?id=21245#c11 give the same results?

This was indeed working before 172942.

We're experiencing the same behaviour with Linux, Chrome 25.

Confirmed for Chromium Version 25.0.1364.97 Ubuntu 12.10 (183676)

I can confirm that this is occurring on Mac OSX Chrome Version 25.0.1364.152

I can confirm this is happening with Version 25.0.1364.160 m on windows 7. 
 

I can confirm this is happens with Google Chrome version 25.0.1364.152 on Ubuntu 12.04 LTS

And 26.0.1410.28 beta on OSX

Seeing the same bug on Chrome 25.0.1364.152 on Windows 7

http://trac.webkit.org/changeset/137607 appears to have turned an ancient WebKit quirk into a bug. I'm working on it.

Thanks!

Patch posted upstream at https://bugs.webkit.org/show_bug.cgi?id=112194

Fixed on trunk: http://trac.webkit.org/changeset/145735

 Issue 190580  has been merged into this issue.

I left this issue open because I don't know if this is something we care about merging.

mmenke, do you have an opinion?

We've received enough reports of this that I think it's worth merging.  Also, doing extra POSTs instead of GETs strikes me as pretty bad, and the fix doesn't look too complicated.

The fix is a 1-liner that's used called during every network request. I'd like to think something would have gone fantastically wrong by now if it were a toxic change.

Guys - has the fix been validated in the latest M27 canary builds? Please validate there before approving the merge.

 Issue 179167  has been merged into this issue.

 Issue 172431  has been merged into this issue.

tanyarad:  Using the sample site in question, I can confirm this issue used to be reproducible on Canary, and now it works as expected.  Reloading does not show the confirmation dialog, and sends a GET as it should.

The same as above on Chrome 25.0.1364.172 
mac book pro mac os x 10.8.3

The last update (26.0.1410.43 m) to Windows 7 64 bits has solved the problem to me ...

 Issue 225265  has been merged into this issue.

 Issue 21245  has been merged into this issue.

 Issue 21245  has been merged into this issue.

 Issue 21245  has been merged into this issue.

still happens to me on version 26.0.1410.64 windows 7

I'm stilling having this problem in 29.0.1547.62 m, Windows 7 64-bit.

I still experience this bug in Chromium 32.0 on Ubuntu 13.10.

Could someone provide an about:net-internals dump (Link to instructions on that page), or anyone have a URL that reproduces the issue?

The URLs above that used to exhibit the issue are working just as they should.

Oh sorry, I misread the description. In fact it is a different bug that is probably not reported yet.

I suspect 103458 fixed this.

yogu32:  Thanks for the followup!  Please file a new bug.  If it's network related and you email me the link, I'll try and triage it.