Digital Point Image Proxy [Paid] 1.0.4
- Thread starter digitalpoint
- Start date
digitalpoint
Well-known member
Do you have a sample URL?
Using PHP 5.6 ?Addon worked fine before
Now all I get is this:
However, you load the image url in another window works fine.
If you hover over the img in the inspecter, it shows too.
digitalpoint
Well-known member
PHP 5.6 doesn't matter... I'm using it on my site.
digitalpoint
Well-known member
I suspect something other than just PHP 5.6 is the issue there. I've never had any issues with 5.6 at all (and I know a few others using it with 5.6 as well).
digitalpoint
Well-known member
Looks like your web server is kicking back an invalid HTTP Status Code.
Specifically, your server is serving up the image just fine, but instead of a "200 OK" response, it's giving a "404 Not Found" response. Which is confusing the browser... it doesn't try to embed the image since the server said it's not there and it just assumes the content being returned in the error page. But opening it directly shows the content, because the browser thinks you are viewing the error page.
Ultimately you probably need to talk to your server admin and see if you have a weird rule somewhere in your Apache config (or .htaccess files) that are forcing the 404 HTTP header. Maybe at the application level if you have something like an add-on that is changing the HTTP status header for some reason.
As a test, if you go to the DigitalPointImageProxy/ControllerPublic/Proxy.php file and find this:
PHP:
header('Cache-Control: public, max-age=31536000');
PHP:
header('Cache-Control: public, max-age=31536000', true, 200);That should force an HTTP 200. It doesn't solve the problem of something weird setting the 404 somewhere in your config, but let me know if it fixes it for you. Might be worth it to add it to the source on my end to make less support issues for me.
JordanH
Well-known member
This seems to not fix the issue.Looks like your web server is kicking back an invalid HTTP Status Code.
Specifically, your server is serving up the image just fine, but instead of a "200 OK" response, it's giving a "404 Not Found" response. Which is confusing the browser... it doesn't try to embed the image since the server said it's not there and it just assumes the content being returned in the error page. But opening it directly shows the content, because the browser thinks you are viewing the error page.
Ultimately you probably need to talk to your server admin and see if you have a weird rule somewhere in your Apache config (or .htaccess files) that are forcing the 404 HTTP header. Maybe at the application level if you have something like an add-on that is changing the HTTP status header for some reason.
As a test, if you go to the DigitalPointImageProxy/ControllerPublic/Proxy.php file and find this:
and change it to this:PHP:header('Cache-Control: public, max-age=31536000');
PHP:header('Cache-Control: public, max-age=31536000', true, 200);
That should force an HTTP 200. It doesn't solve the problem of something weird setting the 404 somewhere in your config, but let me know if it fixes it for you. Might be worth it to add it to the source on my end to make less support issues for me.
digitalpoint
Well-known member
In that case, it's gonna be something you are going to need to trace with your server admin. Something in your server config is overriding the HTTP status there upstream of the application (mostly likely the web server).
Hi,
Having the same issue as JordanH and want to see if I can shed a little bit more light into this to see if we can pinpoint the problem.
This only happens for some images and not all. I can confirm the HTTP response returned is 404 for the problem images.
Also realized that if I disable mcrypt encryption and just go with the base64_encode method in DigitalPointImageProxy/Helper/Encryption.php, the problem images load okay and the HTTP response is 200.
Having the same issue as JordanH and want to see if I can shed a little bit more light into this to see if we can pinpoint the problem.
This only happens for some images and not all. I can confirm the HTTP response returned is 404 for the problem images.
Also realized that if I disable mcrypt encryption and just go with the base64_encode method in DigitalPointImageProxy/Helper/Encryption.php, the problem images load okay and the HTTP response is 200.
digitalpoint
Well-known member
Do you have a sample image URL hat it happens with?
Here's an example of an image that always returns 404:
http://dev.gtswarm.com/proxy/fg6LzOACSJF2r2qKo3nc8e4PEGwoqIwhCqh+SW5RuReebtk1zlzLZWyspw6gRkRHtM/NTcGt/image.png
Original: http://johnlei.com/sports-images/smelter_touchdown.jpg
Here's an example that (as far as I know) always returns 200:
http://dev.gtswarm.com/proxy/fg6LzOACSJF2r2qKo3nc8e4PEGwoqIwhCqh+SW5RuReeby3mBawxsmfANTABNQxwH7Xa/image.png
Original: http://johnlei.com/sports-images/robert_godhigh.jpg
Last edited:
digitalpoint
Well-known member
No, I mean the actual image URL that is being proxied.
digitalpoint
Well-known member
I tested the image on my end and it seems to return the correct HTTP status code when being proxied (200). Most likely you have something on your server that is overriding the HTTP status codes upstream of the application (XenForo).
Maybe something in your Apache config that sees it's a ".png" file, then looks in the file system for it, doesn't find the file (since it's not an actual file), then overrides the HTTP status code since ti couldn't find it.
You could probably test that by commenting out this line in the DigitalPointImageProxy/Route/Prefix/Proxy.php file:
That should generate the URLs without the file extension (which is probably what your server is keying on).
If you want to actually fix the root of the problem and stop your web server from trying to be smarter than the application being run (and stop trying to validate the existence of files with certain extensions), you probably will need to talk to your server administrator.
Maybe something in your Apache config that sees it's a ".png" file, then looks in the file system for it, doesn't find the file (since it's not an actual file), then overrides the HTTP status code since ti couldn't find it.
You could probably test that by commenting out this line in the DigitalPointImageProxy/Route/Prefix/Proxy.php file:
PHP:
// $extension = 'png';That should generate the URLs without the file extension (which is probably what your server is keying on).
If you want to actually fix the root of the problem and stop your web server from trying to be smarter than the application being run (and stop trying to validate the existence of files with certain extensions), you probably will need to talk to your server administrator.
I've attempted this as well to no avail.
Attempted to find if there are any errors logged at either the apache or php level and didn't find anything unusual. Aside from seeing the 404 response code in the access logs, the issue does not generate any errors. Also tried disable ModSecurity to see if that was the culprit and took a look at the apache rewrite in case I was doing something unusual.
For the time being, I'll just take out the mcrypt encoding/decoding methods just to get this working. Will look at messing around with that in dev instance to see if I can come up with anything.
Thanks!
digitalpoint
Well-known member
What Apache modules are you running on that server?
Code:
root@ [~]# httpd -M
Loaded Modules:
core_module (static)
authn_file_module (static)
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
authz_default_module (static)
auth_basic_module (static)
include_module (static)
filter_module (static)
deflate_module (static)
log_config_module (static)
logio_module (static)
env_module (static)
expires_module (static)
headers_module (static)
unique_id_module (static)
setenvif_module (static)
version_module (static)
proxy_module (static)
proxy_connect_module (static)
proxy_ftp_module (static)
proxy_http_module (static)
proxy_scgi_module (static)
proxy_ajp_module (static)
proxy_balancer_module (static)
ssl_module (static)
mpm_itk_module (static)
http_module (static)
mime_module (static)
status_module (static)
autoindex_module (static)
asis_module (static)
info_module (static)
suexec_module (static)
cgi_module (static)
negotiation_module (static)
dir_module (static)
actions_module (static)
userdir_module (static)
alias_module (static)
rewrite_module (static)
so_module (static)
passenger_module (shared)
disable_suexec_module (shared)
bwlimited_module (shared)
cloudflare_module (shared)
security2_module (shared)
Syntax OKdigitalpoint
Well-known member
Is that a dev server where you could disable all but necessary modules just to see if it *is* one of the Apache modules doing something?
Similar threads
