The last 2-3 days some of our users have been reporting this error. Random pages on our site will output raw binary data. None of the developers can duplicate the issue which comes and goes randomly.
All users reporting the issue have so far been using IE11. The server is Apache 2.4.16 with PHP 5.3.29. There are NO errors being logged by PHP or by Apache related to the issue.
Oddly the HTTP header is embedded in the middle of the data. I can't even fathom a reason that would ever happen. One would expect that if the browser was having issues rendering the content, then it wouldn't be making further requests for more resources to the server and there wouldn't be another HTTP header to show.
We really don't know where to start with this one, we can't tell if it's server, php code, or browser related. Is anyone aware of bugs in Apache or IE that would cause this?
Attached is a screenshot one of the users sent.
I found the bug. The PHP code was generating a 302 redirect, but then also outputting it's normal page content. In certain high load conditions outputting the page could take 3-5 seconds. For some still undetermined reason the output from the first (redirected) request was being munged onto the beginning of the new request before that request's headers, turning the entire thing into garbage.
If anyone knows why THAT behavior - the content of one terminated request being prepended onto a new active request - is happening feel free to answer the question so I can fully mark it solved.
Related
I have a file "host.php" which gives plain text. When I try to run it in browser, once per few refreshes one variable increases by 2, not 1. I tried placing session variable on end, to check if its script error (double var increment) or a http error. Looks like it increases the same way. Also checked Chrome Network debugger. Found one error (with browser trying to load favicon.ico), fixed it and the problem still occurs.
I have seen this question:
What can cause a double page request? which had the same problem, but it wasn't solution for me. I don't use ads or html elements - its plain text.
The result:
The page sometimes loads twice. There is no network errors, like empty src. And its plain text, not html.
The question:
How to fix it? How to prevent page loading twice?
PS: The page never uses POST requests, only get.
I'm not sure is it the correct answer, so I won;t yet mark it as correct.
When I tried the script in Chrome on other device (in Incognito mode), everything worked well (or I just didn't saw...). On my device I'm also using Chrome.
As Incognito mode uses different cookies probably even for each tab (?), it might be fault of some external cookies running (like in linked question, ads could import some). Chrome debugger now only shows 1 cookie, which is PHPSESSID from my site, it looks like its not that.
Afterall, I pressume that its user's device/browser/extensions fault. I also tried disabling Adblock, but that didn't solve the problem.
I've really big problem with my website: http://ap.v11.pl/sklep/
It loads really slow and I dont know how to fix that.
I've getting some weird errors from Chrome console: http://scr.hu/0an/xq5bz
There errors are random, for example i'm getting error that something cant be found but this resource exists and the paths are good.
My htaccess:
http://pastebin.com/ewZZBLFg
Page is working on ZendFramework 2
Thank you for any advices
My hypothesis is:
you are running Ghostery as Chrome plugin or something similar so that e.g. your browser will block a couple of your scripts like the adstat thing and google analyticis
your webserver has a problem sending the correct mime type for the javascript stuff. Check out this posting on the "resource interpreted as a ..." error message
It may be that only one frontend is not working correctly. This would explain why you get the errors not all the time.
In general your site is packed with scripts and images. The first page has > 250 requests & almost 4 Mb. That's very much and it takes time. Amazon's Frontpage has half the number of requests and something like 300kb.
You should check if you can reduce the number of requests - the yslow plugin may give you some good advise here. Can you reduce the image size and number of image? (css sprites?)
You should also check if you have to deliver all the images through your regular web browser or if you can use a lightweight alternative. Are you using NGINX? AFAIK it has good options for performance tunings.
Edit: As a starting point: http://gtmetrix.com/reports/www.ap.v11.pl/fBGKScZ6
We're seeing an issue that sounds identical to the one reported here:
Intermittent empty $_POST issue
I'm not sure if that question was ever resolved (but I don't have the ability to comment on that post).
It is an extjs form submitted thousands of times a day (json encoded data), with maybe 20 failures getting logged (to a text log we're keeping) each day. We're on Apache, PHP 5.3.14.
We've done extensive searches on users experiencing empty and truncated POST data and tried a number of things, including:
checking value of php://input (also empty/truncated)
checking/increasing config settings like post_max_size
explicitly setting content type
experimenting with keepalive settings
when data is truncated, it is seemingly random (not special characters)
the length of data POSTed doesn't seem to be a factor (truncates at random place, independent of how many fields are being POSTed back)
One potential clue is that when the POST comes back completely empty, it seems to always be with Internet Explorer or Safari. For the ones that are truncated, it doesn't appear to be specific to a particular browser (so it is possible that there are two separate problems at work here).
We're running out of ideas about what to try -- any ideas?
We found something in our app that could have been causing the problem. We had a menu that used javascript and it was doing a form submission, i.e. document.formname.submit(). People were clicking on the menu before the whole page was loaded. This submission had the potential to submit part of a form. This was a javascript HTML issue not server related.
How can I prevent (unauthorized) people from reading a message on a website (e.g. by looking in the browser cache for the text/images)?**
It's a PUBLIC (!) site (means: no logins here!)
But:
the (secret) message is only shown for a certain time.
the message might be shown only if a passwort is given.
Problems:
In Opera for example page(=page contents/text) could be indexed by the browser and searched.
One idea was to create an image with the message ... but: Also images - even when a header "no cache" is send could be retrieved from FireFox's cache.
Also: Recreating the message from single characters as image does not work (at least I think so at the moment). I tried this method, but it makes output quite slow (writing this: I notice that I do not need to create the images at runtime, but could create images (of single letters) in advance and display/refer to them not by real, but pseudo random names in the HTML )
I also had the idea to output a encoded message (ROT13) (in HTML) but use JS .onload to decode the message immediately. Problem: If this code is in the HTML it could be recovered from the cache later on. At least if someone searches through the (Opera) cache the person would probably not think of entering search terms encoded.
Programming language is PHP.
You can't. What if someone takes a screenshot of this?
You could add the secret code to the page with javascript, after the page is loaded. You'd want to retrieve the secret code via AJAX, then write it to the page - that way, the code isn't cached in the HTML part of the source, and it isn't sitting in the javascript within the page's source code.
Content piped in with AJAX is pretty ephemeral, it won't be cached or otherwise recorded.
Since I don't know anything about your HTML or what (if any) javascript framework you might be using, I can't give you a code sample, but you should be able to work with the concept.
Realistically if it is sent to the client and displayed on screen then you can not prevent the message from being saved or stored on the client machine. Whatever you do to prevent that save could still be bypassed by a simple screenshot.
If you are not concerned about the person the message is targeted at saving said message then I think your best course of action would be to use Flash with Flash doing a call to the server to retrieve the message and display it. Another option may be to use javascript to perform some form of call (AJAX) to the server which then sends back the message and you alter the DOM to display the message. I don't think that would be cached but unless you use SSL it could be stored by intermediate proxies.
I need to confirm something before I go accuse someone of ... well I'd rather not say.
The problem:
We allow users to upload images and embed them within text on our site. In the past we allowed users to hotlink to our images as well, but due to server load we unfortunately had to stop this.
Current "solution":
The method the programmer used to solve our "too many connections" issue was to rename the file that receives and processes image requests (image_request.php) to image_request2.php, and replace the contents of the original with
<?php
header("HTTP/1.1 500 Internal Server Error") ;
?>
Obviously this has caused all images with their src attribute pointing to the original image_request.php to be broken, and is also the wrong code to be sending in this case.
Proposed solution:
I feel a more elegant solution would be:
In .htaccess
If the request is for image_request.php
Check referrer
If referrer is not our site, send the appropriate header
If referrer is our site, proceed to image_request.php and process image request
What I would like to know is:
Compared to simply returning a 500 for each request to image_request.php:
How much more load would be incurred if we were to use my proposed alternative solution outlined above?
Is there a better way to do this?
Our main concern is that the site stays up. I am not willing to agree that breaking all internally linked images is the best / only way to solve this. I refuse to tell our users that because of something WE changed they must now manually change the embed code in all their previously uploaded content.
Ok, then you can use mod_rewrite capability of Apache to prevent hot-linking:
http://www.cyberciti.biz/faq/apache-mod_rewrite-hot-linking-images-leeching-howto/
Using ModRwrite will probably give you less load than running a PHP script. I think your solution would be lighter.
Make sure that you only block access in step 3 if the referer header is not empty. Some browsers and firewalls block the referer header completely and you wouldn't want to block those.
I assume you store image paths in database with ids of images, right?
And then you query database for image path giving it image id.
I suggest you install MemCached to the server and do caching of user requests. It's easy to do in PHP. After that you will see server load and decide if you should stop this hotlinking thing at all.
Your increased load is equal to that of a string comparison in PHP (zilch).
The obfuscation solution doesn't even solve the problem to begin with, as it doesn't stop future hotlinking from happening. If you do check the referrer header, make absolutely certain that all major mainstream browsers will set the header as you expect. It's an optional header, and the behavior might vary from browser to browser for images embedded in an HTML document.
You likely have sessions enabled for all requests (whether they're authenticated or not) -- as a backup plan, you can also rename your session cookie name to something obscure (edit: obscurity here actually doesn't matter as long as the cookie is set for your host only (and it is)) and check that a cookie by that name is set in image_request.php (no cookie set would indicate that it's a first-request to your site). Only use that as a fallback or redundancy check. It's worse than checking the referrer.
If you were generating the IMG HTML on the fly from markdown or something else, you could use a private key hash strategy with a short-live expire time attached to the query string. Completely air tight, but it seems way over the top for what you're doing.
Also, there is no "appropriate header" for lying to a client about the availability of a resource ;) Just send a 404.