Browser downloads file instead of displaying it - header

I am using php readfile to send a file to the browser. Its is an image file. Howver the browser downloads it, instead of displaying it.
This is the response header:
HTTP/1.1 200 OK
Date: Tue, 15 Jan 2013 14:11:46 GMT
Server: Apache
X-Powered-By: PHP/5.3.18-nmm1
Content-disposition: attachment; filename=test.jpg
Content-Length: 20599
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: image/jpeg; charset=binary
Why doesnt it display?

The bad guy is this line:
Content-disposition: attachment; filename=test.jpg
Try to remove it in order to show the image in the browser.
Alternatively, use a small html file, as this is the way a browser is supposed to work ;)

Related

Jmeter not showing up proper response instead giving details of server and connection details

I am using Jmeter 5.4.1 version, my API is of oauth1.0 type. When I ran my api through postman , it gave my proper json response for example an proper id, but the same api when ran through jmeter gives 200 response code but giving details of server and connection in response body and not the reponse that is expected(a proper id).
Below is the response :
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 12 May 2021 12:33:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=eqvp0l22u2jo30moqn194meugp; expires=Wed, 12-May-2021 13:33:10 GMT; Max-Age=3600; path=/; domain=dev.moorup.no; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Cache-Control: no-store
enter image description here
You're looking at Response Headers tab of the View Results Tree listener therefore you're seeing the HTTP Response Headers
Just switch to Response Body tab and you will be able to see "raw" HTML Response and several options of rendering it:
Also be aware that it is possible to convert your Postman scripts to JMeter, for OAuth you will still have to do some correlation, but for the main logic record and replay should work more or less fine

HTML Header indicates image/jpeg, DevTools indicates document and cache is not working

I am trying to cache some images and using the DevTools of MS Edge to analyze the network.
The URL should return only the image via readfile($image) and I see the image correctly in the browser.
Response Headers:
HTTP/1.1 200 OK
Date: Mon, 25 May 2020 19:18:56 GMT
Server: Apache/2.4.38
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: max-age=86400
Pragma: no-cache
Debugbar-Time: 1590434336
Debugbar-Link: https://blog.casa.spiti/?debugbar_time=1590434336
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/jpeg
The Network Tab of the Chrome Dev Tools shows document for the image.
Questions to this output:
What is this expire date of 1981? How do I change it?
Is this the reason why the image is not cached?
Why is the image being indicated as document? Is it because I use readfile()?
Impossible to answer without seeing your server config.
Shouldn’t be, cache-control is used in preference to Expires.
If you are loading the image directly in the browser it shows as document - even if it’s an image. That image is the document in that case. If you load the image as part of an HTML document, then it will show as Image in Dev Tools.

How to fetch HTTP response body with lua?

I need to parse retreived text from HTTP GET request. I am using Lua on NodeMCU and I am not very familiar with it.
I am using script to fetch response and to split it one row at a time using this script
local nStart, nEnd = string.find(c, "\n\n")
if (nEnde == nil) then
nStart, nEnd = string.find(c, "\r\n\r\n")
end
c = string.sub(c,nEnd+1)
print("length: "..string.len(c))
data = mysplit(c, "\n") -- fill the field with filenames
HTTP GET request looks like this
GET /lua/node.php?id=4022029&list HTTP/1.1
Host: mydomain.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; esp8266 Lua;)
When I print HTTP response, it looks like this
HTTP/1.1 200 OK
Date: Tue, 28 Nov 2017 01:05:12 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=23p8rtds43pd1662ncm5cjhrl3; path=/
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
When I type mydomain.com/lua/node.php?id=4022029&list, I get a list of files as a text one bellow other, but this script is not fetching anything. It looks like there is no body. What am I missing here?
Update,
My script is working when fetching data from HTTP which is not encoding data chunked, but I am not able to fetch it from chunked encoding.
Transfer-Encoding: chunked
The server you are connecting to is using chunked encoding, which means the header should be followed by one or more chunks that consist of chunk length and the content. It looks like either you haven't finished reading the content or the library you are using doesn't handle the chunked content for some reason.

Linkedin.com returns text/plain if the link opened from flash

I work at a company that makes a web publication software. Yesterday I've stumbled upon the strange bug with opening links from a flash. The link was to a page on linkedin.com site, but maybe it's not the only case.
Here is a test publication:
http://cdiem.cld.bz/Link-test
(Click the "Product guide" text, there is the link to a page on linkedin.com)
For some reason it opens as a plain text in Chrome and Opera (and maybe other Chromium-based browsers), but works fine in Firefox and IE.
It also works fine from HTML version of the publication (disable Flash plugin to see it). And it also works fine if you just reload the page.
My guess is that it has something to do with the X-Requested-With header field, cause it's the only thing I found that differs between the HTTP request from Flash and HTML versions of publication:
X-Requested-With:ShockwaveFlash/16.0.0.305
Could anyone give any advice on that?
I think that you are right about X-Requested-With.
Take these two tests that I did using hurl.it where you can test HTTP requests :
First test : just request our page.
Request headers :
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: runscope/0.1
Response headers :
Cache-Control: no-cache, no-store
Connection: keep-alive
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 6156
Content-Type: text/html;charset=utf-8
Date: Thu, 05 Mar 2015 21:10:50 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
...
Here we can see very clear that server has sent a text/html content.
We do the same test but we will just add the X-Requested-With header.
Second test : request our page with X-Requested-With header.
Request headers :
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: runscope/0.1
X-Requested-With: stackoverflow_test
Response headers :
Cache-Control: no-cache, no-store
Connection: keep-alive
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 3602
Content-Type: text/plain;charset=UTF-8
Date: Thu, 05 Mar 2015 21:21:06 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
...
This time we can see that the server has sent a text/plain content.
So it's clear that the server is changing the Content Type to text/plain when receiving a X-Requested-With header which is sent by Flash Player PPAPI (used in Chrome and Opera) like you can see here.
Hope that can help.

Fiddler doesn't decompress gzip responses

I use Fiddler to debug my application. Whenever the response is compressed by server, instead of decompressed response, Fiddler shows unreadable binary data:
/* Response to my request (POST) */
HTTP/1.1 200 OK
Server: xyz.com
Date: Tue, 07 Jun 2011 22:22:21 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
14
����������������
0
How can I get the response decompressed?
I use fiddler version 2.3.4.4 and just noticed that in the Inspectors tab ("Raw" sub-tab), above the response section (in case of gzip-ed response), appears "Response is encoded and may need to be decoded before inspection. Click here to transform."
If you click on that, the response becomes readable.
The settings are pretty much the default, I just installed Fiddler and did not change anything.
If you don't want to have to click per response as in the accepted answer, using the menu, click Rules -> Remove All Encodings.
From the fiddler faq
Q: I like to navigate around a site then do a "search" for a text on all the logged request/responses. I was curious if Fiddler automatically decompressed gzipped responses during search?
A: Fiddler does not decompress during searches by default, since it would need to keep both the compressed and decompressed body in memory (for data integrity reasons).
In current versions of Fiddler, you can tick the "Decode Compressed Content" checkbox on the Find dialog.
Here is a link to the site
http://www.fiddler2.com/fiddler/help/faq.asp