I'm working on building a PHP based proxy script to access a particular ASP.NET page that uses lots of AJAX. So far most of the website works, but one of the forms produces the following error upon submittal:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html P'.
I've checked the headers that my proxy script sends/receives, and they're identical to what would actually be sent my a web browser like FF. I've checked the page source to make sure everything that should be in tact is so. I've also verified there aren't any javascript errors on the page.
Can anyone suggest an approach to continue troubleshooting the issue?
Thanks.
If you miss an AJAX call in your proxy, there could be some cross domain errors. Also, make sure you are not accidentally stripping any non-standard headers like X-MicrosoftAjax.
Related
I am using file_get_contents() to fetch the contents from a page. It was working perfectly, but suddenly stopped working and started to show the error below:
"Warning: file_get_contents(https://uae.souq.com/ae-en/apple-iphone-x-with-facetime-256gb-4g-lte-silver-24051446/i/): failed to open stream: HTTP request failed! in /home/xxx/xxxx/xxx/index.php on line 6.
So I tried the same code on localserver, it was working perfectly. Then I tried on another server, and it was working perfectly there too. So I contacted the hosting provider, they said the problem is with the url that they may be preventing the access. So I tried another url (https://www.w3schools.com/) and it is getting contents without any error.
Now I am really confused what the problem is. If the problem is with the server, other urls shouldn't have worked. And if the problem is with url, it shouldn't have worked on the second server and local server.
Here is the test code:
<?php
$html= file_get_contents("https://uae.souq.com/ae-en/apple-iphone-x-with-facetime-256gb-4g-lte-silver-24051446/i/");
echo $html;
?>
What is the problem here? Even if the problem is with url or server, why was it working perfeclty earlier?
It sounds like that site (souq.com) has blocked your server. The block may be temporary or it may be permanent. This may have happened because you made too many requests in a short time, or did something else that looked "suspicious," which triggered a mechanism that prevents misbehaving robots from scraping the site.
You can try again after a while. Another thing you can try is setting the User-Agent request header to impersonate a browser. You can find how to do that here: PHP file_get_contents() and setting request headers
If your intention is to make a well behaved robot, you should set the User-Agent header to something that identifies the request as coming from a bot, and follow the rules the site specifies in its robots.txt.
I am trying to serve a json data file using content from a database to be used by a dojo widget (dijit.form.FilteringSelect). All the parts seem to be working, but when it's all wired up the ajax call for data returns a 500 error.
In php, I am serving the file using
header('Content-Type: application/json');
Accessing the URL using a browser (Chromium or Iceweasel) initiates a download of the file. The data looks fine. If I save the file back to the server and serve it as a static json file it works just fine.
However if I connect the widget to the data file that is processed by PHP and watch the network connections using Firebug or the Chromium dev tools, the data call returns a 500 error from apache. Looking at the apache log files there is no mention of a php issue, just a one liner showing the request was returned 500.
This happens whether I use a .php file extention or add a special handler for the .json file to be processed by PHP. Again, calling the URL directly returns 200 and the correct data.
What do I need to change in either my PHP code or the apache server so that it will successfully send data requested by dojo?
The development server being used here had the PHP auto_prepend_file value set to include some libraries that included a page templating engine. While this was not causing any issues when the page was called normally (and no templating was being done since the functions were not being called), an error in the included code was causing a bad library to be loaded if the X-Requsted-With GET request header was set to XMLHttpRequest, hence the 500 error only when called from the AJAX call. Additionally the library was trapping the errors it generated which is why the php errors weren't showing up anywhere.
Otherwise the header shown in the question is correct.
application/json is a valid header preferred by all common browsers, you may have some error in your json, try checking your json data in http://jsonviewer.stack.hu/ maybe that helps
I have the following tag for when a user is successfully logged in:
header('Location: /members');
It always used to work. Now, however, when I try to load the page, Chrome gives me this error:
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.
On Firefox, I just get a blank page. When I comment the header statement out, it works, but without the redirect (obviously).
I have tried it with output buffering on and off, with the same effect. Any ideas?
Edit: I have a PHP header statement at the beginning of the code that redirects users to the member page if they are already logged in. Could this be affecting it? I'm not getting any headers already sent errors...
Just put error_reporting(E_ALL) and ini_set("display_errors", 1) and you'll see what's wrong.
Install the HTTP extension and use this instead:
http_redirect('/members');
This should do the trick. If you don't have it installed. you can mimic what it does. It's explained in detail on the manual page, the steps in short:
Create an absolute URI from the relative URI as redirects by RFC must have one.
Check if headers have already been send, if so don't send header, otherwise do.
Display a HTTP response body with the link of the redirect.
Exit the script.
If you don't follow the specs, you can not expect that things work with a browser. Many examples given in the internet are not giving conform redirects, so don't be misguided by bad examples.
Next to that - as already suggested by others - turn on error reporting on your development box so you are aware of any notices and warnings that your code produces. Deal with those issues as well.
While logging HTTP requests to a file I have found something I would not expect.
I just put in the log the $_SERVER['REQUEST_URI'].
Guess what I have found, an url with #fragment attached:
18/05: requested cat/page.html#fragment
Note out of 2477 line of logs I found only one line with fragment attached
Everyone know (should) that fragment is never known server-side but only javascript code can get it. So what is happening here?
I am running PHP 5.3 on Apache 2.X (Debian).
Your assertion that "fragment is never known server-side but only javascript code can get it" is a little short-sighted.
Whilst it's true that, in general operation with a conventional browser, a fragment is not included in the request-to-server, there is nothing stopping me from writing whatever I want in an HTTP request.
echo "GET /lol/werent/expecting/this#were_you HTTP/1.1" > /dev/tcp/yourwebsite.com/80
Someone's testing, someone's playing, someone's playing a bizarre hack attempt, or someone's using a buggy browser.
I wouldn't worry about it.
So I just got a nasty surprise when I deployed some code I thought I'd tested. It would seem there must be some difference between my test machine and my server. The exact same code, featuring a header redirect, worked perfectly on my test machine and not at all on the server. The redirect on the server simply didn't happen, leaving a blank page as a result.
The header is called somewhere in the middle of the script - but nothing will have been output yet. It doesn't output anything until the very end of the script. Long after everything else is run. It buffers everything.
Both server and test machine are running the same PhP version, the same Apache version. Is there something in the configuration files that would allow the header to happen for one and not in the other? Is there something else going on here that would cause it to fail?
EDIT:
Here's the line that sets the header:
public function setRedirect($url) {
header('Location: '.$url);
}
And here's the code that calls that:
$url = new URL('index');
$this->layout->setRedirect($url->toString());
Where URL::toString() always generates a fully qualified domain name, in this case: http://domain/index.php?action=index
I checked both Php and Apache error logs. Nada.
Probably there was some whitespace or other form of output before the header call.
This is only work if you the ini setting output-buffering is on (or if you explicitly start output buffering, but in that case, the redirect should work in both computers).
You can confirm this by turning on error reporting.
Use Fiddler or some other client-side tool to check your headers. Determine that the Location: header is actually being sent. Also, some browsers are picky in the order that headers need to be sent.
I think the most likely explanation is that an error is causing the script to exit on your server, and you have display errors turned off (hence the blank screen). I would suggest checking the Apache error long on your server to see if PHP is putting something in there.
Otherwise you could use a browser extension like LiveHTTPHeaders (for Firefox) to see if the location header is being sent at all, or try debugging the script to see if it's even getting as far as that header call.
I think your server puts some script in your pages to track visitors and give you traffic stats or for a similar purpose. Ideally, you should get an error for this but may be your server has error reporting disabled which gives you a blank page.
I suggest you to run a script with a syntax error and check weather your server has error reporting disabled.