Closed (fixed)
Project:
Drupal core
Version:
6.2
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
23 Feb 2006 at 11:42 UTC
Updated:
22 May 2011 at 02:30 UTC
Jump to comment: Most recent file
I discovered a bug in Drupal's HTTP request (drupal_http_request); overriding the $data variable on redirect.
// This will redirect to "http://drupal.org/"
drupal_http_request('http://www.drupal.org/', array('Content-Type' => 'application/x-www-form-urlencoded'), 'POST', 'key=value');
The first request/response looks as follows
POST / HTTP/1.0
Host: www.drupal.org
User-Agent: Example (+http://www.example.com/)
Content-Length: 9
Content-Type: application/x-www-form-urlencoded
\r\n
key=valueHTTP/1.1 301 Moved Permanently
Date: Thu, 23 Feb 2006 11:30:13 GMT
Server: Apache
Location: http://drupal.org/
Content-Length: 290
Connection: close
Content-Type: text/html; charset=iso-8859-1Now Drupal will try to follow the redirect to http://drupal.org/ but $data gets overwritten here
// well... as soon as i post these lines (line 367-372 from common.inc)
// I get a "Request terminated because of suspicious input data".
and so the next request will look as follows
POST / HTTP/1.0
Host: drupal.org
User-Agent: Example (+http://www.example.com/)
Content-Length: 492
\r\n
HTTP/1.1 301 Moved Permanently
Date: Thu, 23 Feb 2006 11:30:13 GMT
Server: Apache
Location: http://drupal.org/
Content-Length: 290
Connection: close
Content-Type: text/html; charset=iso-8859-1
\r\n
HERE THE HTML RESULT OF FIRST REQUEST| Comment | File | Size | Author |
|---|---|---|---|
| #4 | http_request_patch.txt | 1.69 KB | ebruts |
| #2 | common.inc_20.patch | 1.41 KB | ebruts |
| common.inc_19.patch | 651 bytes | ebruts |
Comments
Comment #1
ebruts commentedI think I set the wrong status.
Comment #2
ebruts commentedMy patch was a bit hasty.
It also overrides the headers as you can see by comparing the first and second request.
Comment #3
dries commentedThanks for the patch. Looking at it, I can't figure out what you changed. I can see some variable names being changed, but other than that? I'm sure I'm missing something. Care to elaborate? Thanks.
Comment #4
ebruts commentedYes only the variablenames changed.
I tried to make it more clear but got that "Request terminated because of suspicious input data" everytime I tried to post some PHP code.
I still have the problem so I will attach my post as a text file.
Comment #5
Crell commentedTo post PHP code in a comment, surrounded it with the "PHP Element" delimiters:
Comment #6
dries commentedGot it now! Makes sense so I committed it to HEAD. Thanks.
Comment #7
(not verified) commentedComment #8
zilla commentedthanks - i'm having this issue right now as well - but i know very little about patching - could you please explain at a grade school level which file i need to go to and how i patch or if i can just cut and paste code from the patch? would be VERY helpful...
could i simply browse cvs.drupal.org and grab the most recent common.inc file
at:
http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/common.inc?view=log
and then simply upload and overwrite the existing file?
Comment #9
Lucict commentedI am running version 6.2 on a private server with Apache 2.0 and PHP5 and am currently experiencing this issue. Looking at my common.inc file, I can see that the patch posted here has already been integrated, so my thought is that I may have an issue with the configuration of my server.
Are there any known Apache 2 or PHP5 settings that may be causing this error?
Or would it be possible that my firewall is blocking a port that needs to be open?
I found some good information on patching here: http://drupal.org/node/30466 In the comments and responses there are some commands and options to try.
Comment #10
lameei commented+1
Comment #11
lameei commentedWhat to do for 6.8? please help. I couldn't find anything for this version.
Comment #12
sobi3ch commentedSame problem on internat sever but I never have this with d5 on same machine, this is not first installation.
Comment #13
alienzed commentedso, was this ever fixed?