|
If you were logged in you would be able to see more operations.
|
 Google issue summary
|
|
|
|
Time Tracking:
|
|
Original Estimate:
|
6 hours
|
|
|
Remaining Estimate:
|
6 hours
|
|
|
Time Spent:
|
Not Specified
|
|
|
|
| Fix Version Priority: |
Should Have
|
Not sure if other web servers are affected, but I'm assuming so. I've tested both apache 1.3 and 2.2 with php 4.4 and 5.2 respectively (php as a module of course). To reproduce ... Go here:
http://framework.zend.com/docs/quickstart
Now, setup your browser to proxy through 67.15.229.40. In Firefox go to Tools > Options -> Advanced Tab -> Network Tab -> Connection Settings Button. Select manual proxy configuration, enter the IP in the http proxy field and use 80 for the port. Click OK, and click OK.
Now refresh and you'll see:
The reason is, when http is used with a proxy request apache turns the REQUEST_URI server var into a fully qualified URI. In this case, instead of the request uri being /docs/quickstart it becomes http://framework.zend.com/docs/quickstart and hence why the error is saying http: is an invalid controller, because when request uri is split on / http: is the first param in the request.
This all may not mean much to you, but for development and monitoring we use this all the time. Furthermore, although its very rare, some people do actually use proxies setup in their browsers.
So what to do? I'm not entirely sure I can make a sound recommendation, but just browsing through Zend_Controller_Request_Http it seems that we are fully counting on and trusting web servers. setRequestUri() simply takes a server var and sets it up as the request uri, no validation what so ever. A fairly safe assumption I'd say heh, but in this case there is an exception. So I'm thinking, why not take the logic that happens in the constructor and move it down into setRequestUri()? In other words, use the power of Zend_Uri and make sure only the "path" part of a uri is ever set as the request uri member?
In the mean time I'm just replacing this:
$requestUri = $_SERVER['REQUEST_URI'];
With:
$requestUri = preg_replace(
'/^https?:\/\/' . $_SERVER['HTTP_HOST'] . '/i',
'',
$_SERVER['REQUEST_URI']
);
FYI, this might show up in the zf general mailing list too. I'm having all sorts of trouble with my subscription and I don't think my emails ever did get through, but maybe they will ...
|
|
Description
|
Not sure if other web servers are affected, but I'm assuming so. I've tested both apache 1.3 and 2.2 with php 4.4 and 5.2 respectively (php as a module of course). To reproduce ... Go here:
http://framework.zend.com/docs/quickstart
Now, setup your browser to proxy through 67.15.229.40. In Firefox go to Tools > Options -> Advanced Tab -> Network Tab -> Connection Settings Button. Select manual proxy configuration, enter the IP in the http proxy field and use 80 for the port. Click OK, and click OK.
Now refresh and you'll see:
The reason is, when http is used with a proxy request apache turns the REQUEST_URI server var into a fully qualified URI. In this case, instead of the request uri being /docs/quickstart it becomes http://framework.zend.com/docs/quickstart and hence why the error is saying http: is an invalid controller, because when request uri is split on / http: is the first param in the request.
This all may not mean much to you, but for development and monitoring we use this all the time. Furthermore, although its very rare, some people do actually use proxies setup in their browsers.
So what to do? I'm not entirely sure I can make a sound recommendation, but just browsing through Zend_Controller_Request_Http it seems that we are fully counting on and trusting web servers. setRequestUri() simply takes a server var and sets it up as the request uri, no validation what so ever. A fairly safe assumption I'd say heh, but in this case there is an exception. So I'm thinking, why not take the logic that happens in the constructor and move it down into setRequestUri()? In other words, use the power of Zend_Uri and make sure only the "path" part of a uri is ever set as the request uri member?
In the mean time I'm just replacing this:
$requestUri = $_SERVER['REQUEST_URI'];
With:
$requestUri = preg_replace(
'/^https?:\/\/' . $_SERVER['HTTP_HOST'] . '/i',
'',
$_SERVER['REQUEST_URI']
);
FYI, this might show up in the zf general mailing list too. I'm having all sorts of trouble with my subscription and I don't think my emails ever did get through, but maybe they will ... |
Show » |
Sort Order:
made changes - 22/Apr/08 12:09 AM
| Field |
Original Value |
New Value |
|
Description
|
Not sure if other web servers are affected, but I'm assuming so. I've tested both apache 1.3 and 2.2 with php 4.4 and 5.2 respectively (php as a module of course). To reproduce ... Go here:
http://framework.zend.com/docs/quickstart
Now, setup your browser to proxy through 67.15.229.40. In Firefox go to Tools > Options -> Advanced Tab -> Network Tab -> Connection Settings Button. Select manual proxy configuration, enter the IP in the http proxy field and use 80 for the port. Click OK, and click OK.
Now refresh and you'll see:
Error!
An error occurred with this request: Invalid controller specified (http:).
The reason is, when http is used with a proxy request apache turns the REQUEST_URI server var into a fully qualified URI. In this case, instead of the request uri being /docs/quickstart it becomes http://framework.zend.com/docs/quickstart and hence why the error is saying http: is an invalid controller, because when request uri is split on / http: is the first param in the request.
This all may not mean much to you, but for development and monitoring we use this all the time. Furthermore, although its very rare, some people do actually use proxies setup in their browsers.
So what to do? I'm not entirely sure I can make a sound recommendation, but just browsing through Zend_Controller_Request_Http it seems that we are fully counting on and trusting web servers. setRequestUri() simply takes a server var and sets it up as the request uri, no validation what so ever. A fairly safe assumption I'd say heh, but in this case there is an exception. So I'm thinking, why not take the logic that happens in the constructor and move it down into setRequestUri()? In other words, use the power of Zend_Uri and make sure only the "path" part of a uri is ever set as the request uri member?
In the mean time I'm just replacing this:
{{$requestUri = $_SERVER['REQUEST_URI'];}}
With:
{{$requestUri = preg_replace(
'/^https?:\/\/' . $_SERVER['HTTP_HOST'] . '/i',
'',
$_SERVER['REQUEST_URI']
);}}
FYI, this might show up in the zf general mailing list too. I'm having all sorts of trouble with my subscription and I don't think my emails ever did get through, but maybe they will ...
|
Not sure if other web servers are affected, but I'm assuming so. I've tested both apache 1.3 and 2.2 with php 4.4 and 5.2 respectively (php as a module of course). To reproduce ... Go here:
http://framework.zend.com/docs/quickstart
Now, setup your browser to proxy through 67.15.229.40. In Firefox go to Tools > Options -> Advanced Tab -> Network Tab -> Connection Settings Button. Select manual proxy configuration, enter the IP in the http proxy field and use 80 for the port. Click OK, and click OK.
Now refresh and you'll see:
{noformat}Error!
An error occurred with this request: Invalid controller specified (http:).{noformat}
The reason is, when http is used with a proxy request apache turns the REQUEST_URI server var into a fully qualified URI. In this case, instead of the request uri being /docs/quickstart it becomes http://framework.zend.com/docs/quickstart and hence why the error is saying http: is an invalid controller, because when request uri is split on / http: is the first param in the request.
This all may not mean much to you, but for development and monitoring we use this all the time. Furthermore, although its very rare, some people do actually use proxies setup in their browsers.
So what to do? I'm not entirely sure I can make a sound recommendation, but just browsing through Zend_Controller_Request_Http it seems that we are fully counting on and trusting web servers. setRequestUri() simply takes a server var and sets it up as the request uri, no validation what so ever. A fairly safe assumption I'd say heh, but in this case there is an exception. So I'm thinking, why not take the logic that happens in the constructor and move it down into setRequestUri()? In other words, use the power of Zend_Uri and make sure only the "path" part of a uri is ever set as the request uri member?
In the mean time I'm just replacing this:
{code}$requestUri = $_SERVER['REQUEST_URI'];{code}
With:
{code}$requestUri = preg_replace(
'/^https?:\/\/' . $_SERVER['HTTP_HOST'] . '/i',
'',
$_SERVER['REQUEST_URI']
);{code}
FYI, this might show up in the zf general mailing list too. I'm having all sorts of trouble with my subscription and I don't think my emails ever did get through, but maybe they will ...
|
made changes - 09/May/08 11:09 AM
|
Original Estimate
|
|
6 hours
[ 21600
]
|
|
Fix Version/s
|
|
Next Minor Release
[ 10050
]
|
|
Fix Version Priority
|
|
Should Have
|
|
Remaining Estimate
|
|
6 hours
[ 21600
]
|
Alexander Veremyev made changes - 11/Aug/08 10:26 AM
|
Fix Version/s
|
|
Next Minor Release
[ 10220
]
|
|
Fix Version/s
|
1.6.0RC2
[ 10050
]
|
|
Alexander Veremyev made changes - 27/Aug/08 12:24 AM
|
Fix Version/s
|
|
Next Minor Release
[ 10230
]
|
|
Fix Version/s
|
1.6.0RC3
[ 10220
]
|
|
Alexander Veremyev made changes - 03/Sep/08 12:00 AM
|
Fix Version/s
|
|
Next Minor Release
[ 10241
]
|
|
Fix Version/s
|
1.6.0
[ 10240
]
|
|
made changes - 26/Nov/08 08:35 AM
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Assignee
|
|
Matthew Weier O'Phinney
[ matthew
]
|
|
Fix Version/s
|
|
Next Mini Release
[ 10250
]
|
|
Fix Version/s
|
Next Minor Release
[ 10241
]
|
|
|
Resolution
|
|
Fixed
[ 1
]
|
made changes - 21/Dec/08 06:08 AM
|
Fix Version/s
|
|
1.7.1
[ 10270
]
|
|
Fix Version/s
|
Next Mini Release
[ 10250
]
|
|
|
Bug
Resolved
Major
ZF MVC is not compatible with apache + http protocol proxy requests