Is RewriteProxy sometimes 'losing' FORM POST data?
2 posts
• Page 1 of 1
- Kurisotofa
- Posts: 4
- Joined: 25 Jan 2013, 04:25
Is RewriteProxy sometimes 'losing' FORM POST data?
Below are 2 log entries from the same visitor (=> IP), on the same page (=> Referer), making 2 AJAX calls (=> X-Requested-With) on that page.
Because of same-origin restrictions, I needed to use a RewriteProxy command to forward calls to http://[domain]/prudsys/* to http://data-exchange.frucon.net/prudsys/*
The first AJAX call properly sends through the FORM data, using the POST method.
The second one doesn't seem to send through the FORM data (although it is properly set-up using jQuery AJAX).
This seems to happen randomly, regardless of browser, or any other parameter I could find.
I can't simulate it myself, we can just monitor it using our logs...
Question is: could the RewriteProxy rule be responsible? Is there a workaround for it?
20140311 10:06:44 Debug REQUEST:
Uri=http://data-exchange.frucon.net/prudsys/CategoryBestsellersRecomm
Header=
Connection: Close
Pragma: no-cache
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate
Accept-Language: de
Cookie: or=3615252864; ASPSESSIONIDAAQRDSSQ=PMKNCGGDJNOPBHHKMCGMDDBH; __utma=14661813.1875388015.1394528708.1394528708.1394528708.1; __utmb=14661813.13.9.1394528799204; __utmc=14661813; __utmz=14661813.1394528708.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host: data-exchange.frucon.net
Referer: http://www.samsonite.de/koffer-samsonit ... 3615252864
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
X-BlueCoat-Via: 5dabf131a0a8b7ca
X-Forwarded-For: 62.96.141.8
X-Forwarded-Host: http://www.samsonite.de
X-Forwarded-Server: 217.21.191.240
X-ORIGINAL-URL: /prudsys/CategoryBestsellersRecomm
X-Requested-With: XMLHttpRequest
Method=POST
Data=
20140311 10:06:44 Debug REQUEST:
Uri=http://data-exchange.frucon.net/prudsys/CategoryPageRecomm
Header=
Connection: Close
Pragma: no-cache
Via: ICAP/1.0 172.16.10.15
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate
Accept-Language: de
Cookie: or=3615252864; ASPSESSIONIDAAQRDSSQ=PMKNCGGDJNOPBHHKMCGMDDBH; __utma=14661813.1875388015.1394528708.1394528708.1394528708.1; __utmb=14661813.13.9.1394528799204; __utmc=14661813; __utmz=14661813.1394528708.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host: data-exchange.frucon.net
Referer: http://www.samsonite.de/koffer-samsonit ... 3615252864
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
X-BlueCoat-Via: 5dabf131a0a8b7ca
X-Forwarded-For: 62.96.141.8
X-Forwarded-Host: http://www.samsonite.de
X-Forwarded-Server: 217.21.191.240
X-ORIGINAL-URL: /prudsys/CategoryPageRecomm
X-Requested-With: XMLHttpRequest
Method=POST
Data=REID=Samsonite_DE&Session=912448207&CategoryId=SAMS066
Because of same-origin restrictions, I needed to use a RewriteProxy command to forward calls to http://[domain]/prudsys/* to http://data-exchange.frucon.net/prudsys/*
The first AJAX call properly sends through the FORM data, using the POST method.
The second one doesn't seem to send through the FORM data (although it is properly set-up using jQuery AJAX).
This seems to happen randomly, regardless of browser, or any other parameter I could find.
I can't simulate it myself, we can just monitor it using our logs...
Question is: could the RewriteProxy rule be responsible? Is there a workaround for it?
- Code: Select all
# Prudsys RDE ###
RewriteProxy ^/prudsys/(.*)$ http://data-exchange\.frucon\.net/prudsys/$1
20140311 10:06:44 Debug REQUEST:
Uri=http://data-exchange.frucon.net/prudsys/CategoryBestsellersRecomm
Header=
Connection: Close
Pragma: no-cache
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate
Accept-Language: de
Cookie: or=3615252864; ASPSESSIONIDAAQRDSSQ=PMKNCGGDJNOPBHHKMCGMDDBH; __utma=14661813.1875388015.1394528708.1394528708.1394528708.1; __utmb=14661813.13.9.1394528799204; __utmc=14661813; __utmz=14661813.1394528708.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host: data-exchange.frucon.net
Referer: http://www.samsonite.de/koffer-samsonit ... 3615252864
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
X-BlueCoat-Via: 5dabf131a0a8b7ca
X-Forwarded-For: 62.96.141.8
X-Forwarded-Host: http://www.samsonite.de
X-Forwarded-Server: 217.21.191.240
X-ORIGINAL-URL: /prudsys/CategoryBestsellersRecomm
X-Requested-With: XMLHttpRequest
Method=POST
Data=
20140311 10:06:44 Debug REQUEST:
Uri=http://data-exchange.frucon.net/prudsys/CategoryPageRecomm
Header=
Connection: Close
Pragma: no-cache
Via: ICAP/1.0 172.16.10.15
Accept: application/json, text/javascript, */*; q=0.01
Accept-Encoding: gzip, deflate
Accept-Language: de
Cookie: or=3615252864; ASPSESSIONIDAAQRDSSQ=PMKNCGGDJNOPBHHKMCGMDDBH; __utma=14661813.1875388015.1394528708.1394528708.1394528708.1; __utmb=14661813.13.9.1394528799204; __utmc=14661813; __utmz=14661813.1394528708.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host: data-exchange.frucon.net
Referer: http://www.samsonite.de/koffer-samsonit ... 3615252864
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
X-BlueCoat-Via: 5dabf131a0a8b7ca
X-Forwarded-For: 62.96.141.8
X-Forwarded-Host: http://www.samsonite.de
X-Forwarded-Server: 217.21.191.240
X-ORIGINAL-URL: /prudsys/CategoryPageRecomm
X-Requested-With: XMLHttpRequest
Method=POST
Data=REID=Samsonite_DE&Session=912448207&CategoryId=SAMS066
Re: Is RewriteProxy sometimes 'losing' FORM POST data?
Hello,
Actually, we've never been reported about losing POST data because of ISAPI_Rewrite. It's unlikely.
Please check if you are using the latest build and update if necessary.
Also, please make sure no occasional redirects happen, because in most cases they are the culprit of lost data.
Actually, we've never been reported about losing POST data because of ISAPI_Rewrite. It's unlikely.
Please check if you are using the latest build and update if necessary.
Also, please make sure no occasional redirects happen, because in most cases they are the culprit of lost data.
2 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 0 guests