Bug 6686

Summary: httpd processing not correct for cross domain post
Product: Busybox Reporter: Sagaert Johan <sagaert.johan>
Component: OtherAssignee: unassigned
Status: NEW ---    
Severity: normal CC: busybox-cvs
Priority: P5    
Version: 1.21.x   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Host: ARM Target:
Build: rootfs build with buildroot

Description Sagaert Johan 2013-11-12 21:25:33 UTC 
context: a webpage running on server http:192.168.1.102:7020 is doing a http post to 192.168.1.61

The env variable PATH_INFO does not seem to be correct when doing a cross domain POST : as seen from the REQUEST_URI='/cgi-bin/busctl.cgi/relay/14'
the correct PATH_INFO should be /relay/14.

The problem does not happen if i host all pages on the same device (192.168.1.61) 

I am not sure if the port specifier could cause this.

I saved the environment vars into a file (using a cgi-script): see below

CONTENT_LENGTH='7'
CONTENT_TYPE='application/x-www-form-urlencoded; charset=UTF-8'
GATEWAY_INTERFACE='CGI/1.1'
HOME='/'
HTTP_ACCEPT='application/json, text/javascript, */*; q=0.01'
HTTP_ACCEPT_LANGUAGE='nl,en-us;q=0.7,en;q=0.3'
HTTP_HOST='192.168.1.61'
HTTP_REFERER='http://192.168.1.102:7020/testemd/index.html'
HTTP_USER_AGENT='Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0'
IFS=' 	
'
OPTIND='1'
PATH='/sbin:/usr/sbin:/bin:/usr/bin'
PATH_INFO='/relay'                         <<<<<<- WRONG
PPID='4987'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/opt/www/cgi-bin'
QUERY_STRING=''
REMOTE_ADDR='192.168.1.102'
REMOTE_PORT='5413'
REQUEST_METHOD='POST'
REQUEST_URI='/cgi-bin/busctl.cgi/relay/14'
SCRIPT_FILENAME='/opt/www/cgi-bin/busctl.cgi'
SCRIPT_NAME='/cgi-bin/busctl.cgi'
SERVER_PROTOCOL='HTTP/1.0'
SERVER_SOFTWARE='busybox httpd/1.21.1'
SHELL='/bin/sh'
TERM='vt102'
USER='root'
Comment 1 Denys Vlasenko 2013-11-20 17:28:04 UTC 
(In reply to comment #0)
> context: a webpage running on server http:192.168.1.102:7020 is doing a http
> post to 192.168.1.61

I want to reproduce this, but a simple test worked for me.

Can you show the exact HTTP request which was received?
I can't determine it exactly from your description.

tcpdump, or better, tcpflow would let you easily capture one.