Re: Issue 12718 in chromium: Google Chrome sends GET request for POST form
chro...@googlecode.com
Cc: da...@chromium.org
Comment #29 on issue 12718 by ero...@chromium.org: Google Chrome sends GET
request for POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Issue 20796 has been merged into this issue.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
chro...@googlecode.com
Comment #30 on issue 12718 by ero...@chromium.org: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
I can't reproduce the problem using the PHP script in comment #0.
Also regarding comment #0, note that the URLs are different in the two
outputs, is
that intentional? (the POST was to "alvaro.es/chrome-post-bug.php" whereas
the
GET was to "itcweb.alf/codigo-alvaro/Servidor/web/chrome-post-bug.php")
Like gwilson asks in comment #27, the best way to getting this resolved is
if
someone can provide a simple public URL that reproduces the problem.
Short of that, we will need users to run experiments to gather data, and
narrow down
the point of failure.
Any volunteers? Does anyone reproduce the problem reliably? 100% of the
time? Any
content scripts installed?
The only case I know of where Chrome will (intentionally) send a GET in
place of a
POST is when redirecting through a non-307. (i.e. you do a POST, server
returns a
302 to a new location, now the request is converted to a GET).
chro...@googlecode.com
Comment #31 on issue 12718 by huttnified: Google Chrome sends GET request
I've setup a public script to test for the issue. Source below. I was
actually
using this script back in the fall when I first noticed the issue. But
currently, on
the same machine, the script is working fine. (Occasionally the bug
persists when I
log in to gmail. though.)
Anyways, others should try this script. Maybe the bug WILL show up for
you, in which
case post your findings so hopefully this can get cleared up.
URL: http://sadsteve.com/chrome_bug.php
Source:
<html>
<body>
<h1>Google Chrome POST submit bug checker.</h1>
<p>Enter some text in the form below.</p>
<form action="/chrome_bug.php" method="POST">
<input type="text" name="arg" id="arg"/>
<input type="submit" value="submit"/>
</form>
<p>If the post submits correctly, the text you've entered should echo in
the space
below between the two dotted lines.</p>
<p>----------</p>
<p>
<?php
if (isset($_POST["arg"])){
echo $_POST["arg"];
}
?>
</p>
<p>----------</p>
</body>
</html>
chro...@googlecode.com
Comment #32 on issue 12718 by kAlvaro: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Comment 20:
In my case the behaviour was 100% reproducible in a specific server.
Unluckily, it
was an internal development box and it's been taken offline since I opened
the ticket
in May.
I don't keep any other headers apart from those included in the Whireshark
logs. I
realise I didn't save the response headers from the form itself but I'm
sure I saw
nothing strange in them. And no proxy: just direct connection between my
Windows XP
box and the Windows Server 2003 box. I can also tell you it was running an
old
version of Xampp with this signature:
Apache/2.2.6 (Win32) DAV/2 mod_ssl/2.2.6 OpenSSL/0.9.8g mod_autoindex_color
PHP/5.2.5
Comment 22:
No extensions (they didn't even exist yet in May :) and default cookie
settings.
Comment 30:
If you mean host name, yes, they're different servers as stated. If you
mean path,
they're different because I was working in a subdirectory and when I tested
with
another server I just copied the test case into its document root.
chro...@googlecode.com
Status: Unconfirmed
Owner: ---
Comment #39 on issue 12718 by dgla...@chromium.org: Google Chrome sends
GET request for POST form
http://code.google.com/p/chromium/issues/detail?id=12718
@bobkennedy, your issue is in setting enctype="plain" in the form. IE and
Firefox seem
to just ignore that, since it's not a valid value. Chrome dutifully
attempts to guess that
you're asking to submit form as text/plain and does as you asked. Remove
the errand
attribute and you should be back in business. FWIW, this has nothing to do
with the
ever-elusive, never-ever-reproduced GET-instead-of-POST issue mentioned
above.
chro...@googlecode.com
Comment #40 on issue 12718 by igitur: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Unconfirmed?! Are you serious?! I'm already getting an email per day
because people
bitch about this issue. Imagine the flood I'm going to get now!
chro...@googlecode.com
Comment #41 on issue 12718 by bobkenn...@mail.com: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
@dglazkov
Wow, thanks! Stupid mistake from me in this code (made somewhere a long
time ago).
That enctype should not have been there at all. My problem is solved and
the code is
better now.
Interesting though that my apps were working because of the 'rule' most
browsers
follow that invalid values are ignored. Important to know that Chrome has a
different
approach: update the code by guessing what was meant. Both approaches may
lead to
very different results (as in my case).
If you know what to look for, the interpretation made by Chrome can be
found in the
developer tools window (shows encoding text/plain). I assumed too easy that
code
working in FF/IE means correct code.
An overview of the changes made in the post to the server in a log window
would be a
nice feature...
chro...@googlecode.com
Comment #42 on issue 12718 by elevant.lauri: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
I do not agree that this bug is "elusive". This is not a proper attitude to
address
serious issues raised by the community.
Event though I too struggle to find a reliable way to reproduce it, there
is no
grounds to dismiss this, rather embarrassing, bug. It sucks when you get
angry calls
from your customers after they just "lost" that lengthy form they filled in.
Using a vanilla Chrome I have encountered this issue myself when resuming
from
hibernation. Please note that opening the page in a new tab *always*
provides a
workaround. And of course, using a more mature browser (which is what we
keep
insisting to our customers)
chro...@googlecode.com
Comment #43 on issue 12718 by vaiyach: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Hi.
I have the same problem. I tried going through the thread, and it seems
that a new tab
does indeed work for signing in - I had trouble with IMDB.
Checked Chrome About and it confirms that I am up to date. I am using a
couple of
extensions, but disabling these did not help. However opening up a new tab
and using
the form again did, even with all the extensions enabled.
I hope my input helps.
chro...@googlecode.com
Comment #45 on issue 12718 by da...@chromium.org: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
I'm unable to repro using the test here:
http://sadsteve.com/chrome_bug.php
I've tested the current Chrome 5 beta channel as well as 5.0.358.0
(Developer Build
41965) on Vista.
Is anyone able to repro using the test above? If not, and you still
believe you see
this issue, can you provide a test case or steps to reproduce the problem?
Thanks!
chro...@googlecode.com
Comment #46 on issue 12718 by jdelStrother: Google Chrome sends GET request
Not particularly helpful I know, but I definitely still see this issue from
time to time in 5.0.342.7 on OS X 10.6.2, but can't reproduce at-will. The
only times when I've seen it are on the
login page of a site I develop (http://audioboo.fm/login), which submits a
POST to the same url. When the bug shows up, it submits a GET and so just
looks like the page reloads. At
that point, it seems to continue just submitting GETs until I close the tab
and reopen it. I think it's occurred 3 times since I started using Chrome
around 4 months ago.
chro...@googlecode.com
Comment #47 on issue 12718 by ajaksu: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
This seems to be uncannily similar to issue 6564, which was fixed for that
specific
trigger (tab first loading "chrome-internal:").
Quoting creis:
"As it turns out, visiting chrome-internal: creates a New Tab Page but
doesn't end up
displaying it. This means DidNavigate is never called, so the SiteInstance
has no
site. That leads to the symptoms we're seeing here."
How likely is it that somehow not calling DidNavigate or borking
SiteInstance leads
to this? We don't see the same 'post then get' behavior in the OP's report,
but even
the workaround is the same.
chro...@googlecode.com
Comment #48 on issue 12718 by igitur: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
ajaksu, you just beat me to it. I was about to post this:
I think I might have some sort of test case but I haven't been able to
confirm it. But in the absense of anything else, I'll post it here and
maybe someone else can confirm.
I suspect this bug is due to a race condition.
I've experienced it mostly when my CPU is under a bit of strain. I
would open a new tab and before the 'new tab' page can load
completely, I would start typing a URL in the address bar. I use the
autocomplete from the history and press enter.
I noticed ONCE that after I pressed enter to select a historic URL,
that the 'new tab' URL (chrome://... ) briefly appeared in the address
bar. Then my selected URL came back. The page loaded and all POST
forms acted as GETs.
So I have a suspicion that there is a race condition between the
loading for the selected URL and the new tab page. I believe that my
stressed CPU aggravates the problem because it takes longer for the
new tab page to load and hence I can select a URL from the history
easily before the new tab has loaded.
Can someone else confirm this?
chro...@googlecode.com
Comment #51 on issue 12718 by igitur: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
eroman, no, it happens when I explicitly open a new tab. See my previous
comment.
chro...@googlecode.com
Comment #52 on issue 12718 by brjann: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Comment #48 seems to be spot on. I can reliably reproduce the bug by
pasting the
problematic URL immediately after opening a new tab and quickly hitting
enter. It
doesn't matter if it is the first or a subsequent tab, as long as the
default contents
of the new tab isn't loaded.
chro...@googlecode.com
Comment #53 on issue 12718 by ajaksu: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Got a repro for developers:
1. Start "./chrome --renderer-cmd-prefix='gdb --args'"
2. Create a new tab and paste "sadsteve.com/chrome_bug.php" in the omnibox
3. Go to the console and enter 'run'
4. Try to submit a POST form and send a GET instead
Any suggestions of breakpoints or where to poke to further diagnose this?
chro...@googlecode.com
Status: Available
Labels: -Area-Compat-Web Area-Internals
Comment #54 on issue 12718 by ero...@chromium.org: Google Chrome sends GET
request for POST form
http://code.google.com/p/chromium/issues/detail?id=12718
Nice find ajaksu!
Those steps work nicely, and I am able to reproduce this bug consistently.
For Windows Chrome, can reproduce using similar steps:
chrome.exe --renderer-startup-dialog --no-sandbox
chro...@googlecode.com
Comment #57 on issue 12718 by ajaksu: Google Chrome sends GET request for
POST form
http://code.google.com/p/chromium/issues/detail?id=12718
specialk: I think your issue is a mix of issue 39402 with issue 523, not
the same as
this one (where the POST doesn't work at all).
chro...@googlecode.com
Comment #60 on issue 12718 by bugd...@chromium.org: Google Chrome sends
http://code.google.com/p/chromium/issues/detail?id=12718
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=43879
------------------------------------------------------------------------
r43879 | bre...@chromium.org | 2010-04-07 14:08:51 -0700 (Wed, 07 Apr 2010)
| 5 lines
Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/render_view_host_manager.cc?r1=43879&r2=43878
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/render_view_host_manager_unittest.cc?r1=43879&r2=43878
Set the site instance in all cases when we start a new load. If you
navigate away from the new tab page (or another DOMUI page) before the
DOMUI page commits, the subsequent page will inherit the SiteInstance of
the original page.
BUG=12718,40575
TEST=included unit test
Review URL: http://codereview.chromium.org/1519025
------------------------------------------------------------------------
chro...@googlecode.com
Comment #63 on issue 12718 by i...@seekingalpha.com: Google Chrome sends
http://code.google.com/p/chromium/issues/detail?id=12718
confirmed on chrome 5.0.375.99 on MAC OS X 10.6.3
<form method='post'>
<input type='hidden' name='aaa' value='123' />
<input type='submit' />
</form>
normal click on submit results in normal POST request (even if adding
target='_blank' to form tag)
cmd-click or middle mouse button click results in GET request in new tab
without any parameters
P.S. form with "get" method submits ok with cmd-click or middle button click
chro...@googlecode.com
Comment #64 on issue 12718 by stephanietanng: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
I'm using an up to date version of chrome, 8.0.552.224, and I'm still
experiencing this issue for both $_GET and $_POST method when doing a "View
page source".
The browser displays fine.
chro...@googlecode.com
Comment #65 on issue 12718 by framewor...@gmail.com: Google Chrome sends
http://code.google.com/p/chromium/issues/detail?id=12718
Why says that the bug is fixed???
I have this problem because it's not fixed at all!!
chro...@googlecode.com
Comment #67 on issue 12718 by oga...@gmail.com: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
Yes, I've been annoyed by this bug since chrome 2.XX..., it is now version
9.0.597.94 and a year and half later it is still there, but they decided to
just say it is fixed and move on.
chro...@googlecode.com
Comment #68 on issue 12718 by ero...@chromium.org: Google Chrome sends GET
http://code.google.com/p/chromium/issues/detail?id=12718
If you are still experiencing this, please file a new bug including the
reproduction steps (and you can link to it here).
chro...@googlecode.com
Comment #69 on issue 12718 by johnnyg3...@googlemail.com: Google Chrome
http://code.google.com/p/chromium/issues/detail?id=12718
Maybe it has never ever been a bug really, even if all other browsers
handle post data well.
After some research about the problem, this was the solution for me:
Adding enctype="application/x-www-form-urlencoded" to the <form> tag made
the post data being posted.
So just tell the browser what it will have to send and so he will :-)