I'm having an issue where JPGs are seemingly being corrupted when served.
Curiously, its not all JPG images on my site, only about 5% of them. Here's what a corrupted one looks like:
The bottom half is cutoff. This is what jpeginfo on that file returns:
FS0005-2yme9un7m1rme75z1ek074.jpg 250 x 250 24bit JFIF N 40099 Corrupt JPEG data: premature end of data segment Invalid JPEG file structure: two SOI markers [ERROR]
However, if I download the exact same image using wget, or just copy it directly off the server, it looks fine and appears not to be corrupted:
FS0005-2yme9un7m1rme75z1ek074.jpg 250 x 250 24bit JFIF N 40099 [OK]
This is what curl -I returns:
HTTP/1.1 200 OK
Date: Wed, 08 Jul 2015 11:05:15 GMT
Server: LiteSpeed
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Last-Modified: Wed, 08 Jul 2015 08:58:42 GMT
Content-Type: image/jpeg
Content-Length: 40099
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=604800
Expires: Wed, 15 Jul 2015 11:05:15 GMT
The server is Red Hat 4.4.7-4, the images have been uploaded via WordPress and resized with bfi_thumb
Related
I'm trying to read mp4 files with PHP, my initial code was
$file = 'https://s3-sa-east-1.amazonaws.com/onlytestes/video.mp4';
header('Content-type: video/mp4');
readfile($file);
But that way I couldn't use the length bar of the video, skip or even go back, until the video is 100% loaded.
Of course when I read the file directly (video.mp4) everything is fine.
Get the header of the Amazon request (curl) and forward it. Scrubbing will never work though.
UPDATE:
curl -I https://s3-sa-east-1.amazonaws.com/onlytestes/video.mp4
>>
HTTP/1.1 200 OK
x-amz-id-2: Ykt6rmYagUDTbKW+v2DR63Zb4ZmUJCM8ty7hO+Z/BU9DV5w1PTVEk+khHgMp+eoR7ExxzKy1Ius=
x-amz-request-id: 8F7A552FAB8D8B08
Date: Thu, 13 Jul 2017 08:12:26 GMT
Last-Modified: Wed, 12 Jul 2017 09:46:10 GMT
ETag: "adcafc77564f72b5e21574f4bfc4e927"
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Length: **1386059** < to forward.
Server: AmazonS3
I'm using a php script to upload a file to Amazon S3
$s3->putObjectFile($url,$bucket,$filename, S3::ACL_PRIVATE,array(),array("Content-Type" => "application/json"));
Immediately after the upload, I need to get some information from the file and I call it through Cloudfront but I see that the file is available only after some minutes.
Do you know why and if there is a way to sort this out?
Is there a way to have the file immediately available?
Thank you
It was immediately available for me with this test...
$ date;aws s3 cp foo s3://BUCKET/foo;date;curl -I http://dxxx.cloudfront.net/foo;date
Thu Aug 6 04:30:01 UTC 2015
upload: ./foo to s3://BUCKET/foo
Thu Aug 6 04:30:02 UTC 2015
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 24
Connection: keep-alive
Date: Thu, 06 Aug 2015 04:30:03 GMT
x-amz-version-id: null
Last-Modified: Thu, 06 Aug 2015 04:30:03 GMT
ETag: "5089fc210a3df99a6a04fe64c929d8e7"
Accept-Ranges: bytes
Server: AmazonS3
X-Cache: Miss from cloudfront
Via: 1.1 fed2ed9d8e7c2b37559eac3b2a2386fc.cloudfront.net (CloudFront)
X-Amz-Cf-Id: gEaAkLCqstyAdakXkBvMmSJVrfKjKTD5K9WoyZBHvVZufWuuhclNLQ==
Thu Aug 6 04:30:02 UTC 2015
Perhaps your upload is happening asynchronously and the upload hadn't completed yet?
I have the same website with the same css file being gzipped and served on two separate servers. Viewing the site on one server, the browser properly decompresses it, and uses the styling. But on the other, the browser does not decompress the file. I thought perhaps this is something to do with the headers, but all the resources I've found seem to think the Content-Type and Content-Encoding are the only two headers that matter for decompressing gzip, and those are the same on both servers. Is there another response header that is incorrect?
The working response headers for the .css.gz file:
HTTP/1.1 200 OK
Cache-Control: public, max-age=604800, must-revalidate
Accept-Ranges: bytes
Content-Type: text/css
Age: 353722
Date: Tue, 07 Apr 2015 21:44:23 GMT
Last-Modified: Tue, 29 Oct 2013 17:44:18 GMT
Expires: Fri, 10 Apr 2015 19:29:01 GMT
Content-Length: 33130
Connection: keep-alive
The response headers for the .css.gz file that don't seem to work:
HTTP/1.1 200 OK
Date: Wed, 08 Apr 2015 15:14:11 GMT
Content-Type: text/css
Last-Modified: Tue, 07 Apr 2015 22:42:25 GMT
Transfer-Encoding: chunked
Connection: close
Content-Encoding: gzip
I follow this way compression 1
and
compression 2
how to compression with mod_deflate? I've followed the above link and success to compress but browser can not read compression?
I get an error when I open the css and js files in a browser!
SyntaxError: illegal character
��{{�F�7���"ƫ
and
KÊO©¬NJLÎN/Ê/ÍKÑMÎÏÉ/²RN2H6II�ó>å¿rŸ—Ï9?ýSúg½/úž;RSŸ‘‡™§çZV†¤ü”Êê¤Ääìô¢üÒ¼Ýäüœü"+å$ƒd“”ÔZ�
Response Headers
Connection Keep-Alive
Content-Encoding gzip
Content-Length 127
Content-Type text/css
Date Wed, 18 Dec 2013 07:15:22 GMT
Expires Fri, 17 Jan 2014 14:15:22 +0700
Keep-Alive timeout=5, max=100
Last-Modified Wed, 18 Dec 2013 13:17:18 +0700
Server Apache/2.2.25 (Win32) PHP/5.3.26
Vary Accept-Encoding
X-Powered-By PHP/5.3.26
anybody please...thanks
It looks like you are compressing the code twice, once with PHP and once with mod_deflate.
Could this be the case?
I am using wget in php script to download images from the url submitted by the user. Is there some way for me to determine the size of image before actually downloading it and restricting the size of download to 1mb? Also can I possibly check that the url points to an image only and not an entire website without downloading?
I dont want to end up filling my server with malware.
Before loading you can check headers (you'll have to download them though). I use curl - not wget. Here's an example:
$ curl --head http://img.yandex.net/i/www/logo.png
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 16 Jun 2012 09:46:36 GMT
Content-Type: image/png
Content-Length: 3729
Last-Modified: Mon, 26 Apr 2010 08:00:35 GMT
Connection: keep-alive
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Content-Type and Content-Length should normally indicate that the image is ok