Bug 29761 - [GTK] performs a POST when refreshing a view that was obtained with a GET
Summary: [GTK] performs a POST when refreshing a view that was obtained with a GET
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-25 23:17 PDT by Xan Lopez
Modified: 2009-10-04 13:12 PDT (History)
3 users (show)

See Also:


Attachments
redirectreload.diff (11.08 KB, patch)
2009-10-01 10:15 PDT, Xan Lopez
gustavo: review+
xan.lopez: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2009-09-25 23:17:52 PDT
Quoting from https://bugzilla.gnome.org/show_bug.cgi?id=595348:

I use a web application that handles editing items by having the client POST to
a URL that, when requested, performs the edit. It then redirects the client to
the original URL for viewing the item.

If I perform an edit, and press Refresh after being redirected, epiphany does a
POST to the redirected-to URL rather than a GET.

With the gecko backend, pressing refresh would have resulted in a GET to the
redirected-to URL.

Here's an example.

localhost - - [16/Sep/2009 12:30:17] "GET /view HTTP/1.1" 200 517
 [ now i'll mark the items on the page as read ]
localhost - - [16/Sep/2009 12:30:57] "POST /view/mark_read HTTP/1.1" 302 274
 [ the response redirects the client ]
localhost - - [16/Sep/2009 12:30:58] "GET /view HTTP/1.1" 200 517
 [ fine so far, now I'm back to the view page. I'll now hit refresh ]
localhost - - [16/Sep/2009 12:31:35] "POST /view HTTP/1.1" 404 226
 [ ouch!]

The two problems that are, I guess, related are:

 1. The final request shoudl have been a GET
 2. I was not prompted for confirmation for resumbitting the POSTed information

This happens with epiphany 2.7.92 and webkit 1.1.14. It does not hapen with
epiphany 2.26.3 and xulrunner 1.9.0.14.
Comment 1 Xan Lopez 2009-09-25 23:20:03 PDT
I think this causes automatic posts in bugzilla if you follow a link from a bug after posting, and then come back. Not good :)
Comment 2 Dan Winship 2009-09-26 09:29:45 PDT
I suspect ResourceHandleSoup::restartedCallback needs to do:

    request.setHTTPMethod(String(uri->method));

along with the existing request.setURL, before calling willSendRequest(). (SoupSession will have changed the SoupMessage's method when restarting it in this case.)
Comment 3 Xan Lopez 2009-10-01 10:15:43 PDT
Created attachment 40454 [details]
redirectreload.diff

Patch with Dan's suggestion plus a test for this.
Comment 4 Gustavo Noronha (kov) 2009-10-04 03:40:44 PDT
Comment on attachment 40454 [details]
redirectreload.diff

Thanks!
Comment 5 Xan Lopez 2009-10-04 11:15:39 PDT
The newly added test breaks other test, as the extra line in success200.html adds a new empty line in ~20 test results. Need to either change those or do this in some other way.
Comment 6 Xan Lopez 2009-10-04 13:12:45 PDT
I moved the triggering HTML to a new file, so the old tests won't break. Landed as r49077.