I'm trying to dissect a single HTTP request made to some website --> www.somesite.com ... If I understand correctly, the browser will issue a GET request as such:
GET http://www.somesite.com/index.html HTTP/1.1
Ultimately the server will send a response as such:
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2014 10:00:00 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
.
.
.
</body>
</html>
Assuming this index.html contains images and css and javascript assets, if the response was simply 200 OK, how does the client know to go back and fetch the other assets? Meaning, how does the client know that index.html has been served in its entirety when all it did was simply issue the first GET request?
Well, it is hard to understand, what you want to know. The first get will either return data or redirect elsewhere. When browser receives HTML page, it will parse it to element tree and saves links to download (css, js, images). It downloads them and if they contain references to other resources (js, css, images), it will download them as well. When the queue is empty, browser finishes downloading.
Does this high level description answear your question?
Related
Description
When using the HTTP request sampler in JMeter for a specific website I can't seem to fetch any page other than the home page, http://<website>.com/. If I try to access some other page, say, http://<website>.com/about-us I get a 404 response.
In the request sampler there are two fields Server Name or IP and Path, and I know it's a common error to fill these out incorrectly. I've tried multiple different ways to enter these correctly. IP with and without the about-us part, with and without / etc.
I've tried this with other websites and have seen no problems, so my assumption is that there is something specific to the website I'm testing.
Here is where I get confused about it. When you look in the View Result Tree you see under Request > Request Body a correctly entered get request. If I enter this into my browser, or do a manual get request on this url on https://reqbin.com/ it fetches the website just fine.
The only discrepancy I see between this website and other websites that I don't have this problem with is that the website's about page etc., don't end with a /. If you add the backslash at the end of the URL you can't access the website.
Steps to reproduce
Add HTTP sampler in JMeter
enter server name under Server Name or IP, i.e. www.<website>.com
enter path to Path, i.e. /about-us
run test and watch result in View Result Tree
Expected Result
HTTP Response 200
Actual Result
HTTP Response 404
Response Body
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /about-us</pre>
</body>
</html>
Response Headers
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 147
Vary: Accept-Encoding
Date: Tue, 28 Jan 2020 17:11:37 GMT
Connection: keep-alive
Key notes
The request body GET http://<website>.com/about-us is a valid link if posted in a browser or if used with https://reqbin.com/
the about page doesn't end with a /, I don't know if this is relevant
If you don't share the site hostname with us we cannot help, so far I can only suggest:
Consider building your test plan using HTTP(S) Test Script Recorder or JMeter Chrome Extension, both approaches should create the relevant HTTP Request sampler(s) as building test plan manually opens doors to mistakes (i.e. your configuration can contain non-printable characters like space or line breaks)
Increasing logs verbosity for HTTP protocol components by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http" level="debug" />
and if necessary
<Logger name="org.apache.http" level="debug" />
this way you will see for sure what request(s) JMeter is sending
I have embedded a windows media player in a web page, using the usual <object> and <embed> tags. The video is served by an ashx (http handler). When I try to play the video, I usually (but not always) get an error message telling me that the file extension (ashx) does not match the file format.
This happens in IE (9 & 10) and also in Firefox (latest) with the WMP plugin.
I know that the tags (with classid, etc) are correct because the media player displays and allows me to click the 'play' button.
The ashx returns the correct mime type (video/x-ms-wmv) and a valid file name (somevideo.wmv) in the response headers. I have tried content-disposition attachment and inline.
I have tried urls using 'http://', 'https://', and '//' (which I prefer)
If I put the url (including the .ashx) of the video file in the browser address bar directly, the video downloads and plays.
If I modify the object tag to use a direct path to the video file (/somewhere/somevideo.wmv), it works - but I can't use this as a solution.
The same ashx serves up video and audio in various other formats with out any fuss - it just seems that the embedded windows media player doesn't like it.
This has been working for several years - I think this is some new behavior, though I can't identify what has changed, other than browser updates.
EDIT: a more careful study in Fiddler showed something I missed before. If I access the video directly (by entering my ashx url in the browser address bar), the video plays in the standalone media player. The content type and disposition headers are correct.
However, when using the embedded player, I usually (not always) get OPTIONS and PROPFIND requests from user agent "Microsoft-WebDAV-MiniRedir/6.1.7601". I do not have WebDAV enabled, and I do not respond to options and propfind requests. The embedded player does not request the actual video file.
Correction - I do actually respond to the options request - here is the request and response info from fiddler :
OPTIONS http://mydomain.com/myhandler.ashx HTTP/1.1
User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601
translate: f
Connection: Keep-Alive
Host: mydomain.com
HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Server: Microsoft-IIS/7.5
Public: OPTIONS, TRACE, GET, HEAD, POST
X-Powered-By: ASP.NET
Date: Tue, 24 Dec 2013 16:03:49 GMT
Content-Length: 0
This is followed by four identical requests, using PROPFIND instead of OPTIONS. the response is 404.
To successfully play the file you need to specify Content-Disposition and Content-Type headers correctly.
In your ashx, make sure you add following lines,
Response.AddHeader("Content-Disposition","attachment;filename='a.wmv'");
Response.AddHeader("Content-Type","video/wmv");
Please identify correct name and content-type based on type of file you have, and substitute them in above code.
Looks like it has Cross Origin Resource Sharing Issue,
make sure you are returning correct headers for different domain as suggested by following response.
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: X-Requested-With, Accept, Content-Type, Origin
Access-Control-Max-Age: 1728000
Replace * with domain where your page is hosted which embeds your media player.
Have you tried appending the file type to the end of the URL? for example:
http://www.mywebsite.com/MyVideoHandler.ashx?videofile=123245&.wmv
This example assumes that the file is of wmv type.
I have some js hosted on AWS. I want to cache it to not to pay extra for 304 GET request, but I'm puzzled why two headers are different.
Request Method:GET
Status Code:304 Not Modified
Request header of helper.js
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
If-Modified-Since:Tue, 20 Aug 2013 13:08:13 GMT
and response header
Age:4348
Cache-Control:max-age=604800
Connection:keep-alive
Why they are different? Does it mean that Cache-Control is wrong? I used Chrome console to get the headers.
I don't think that Cache-Control is wrong and it seems that your content is already cached. From the request headers, I understand that the first request was done at Tue, 20 Aug 2013 13:08:13 GMT as the browser indicates the server "hey, has the content changed since that time?". In return, the server responses with 304 Not Modified header, indicating that the content has not been changed and it should be cached 604800 seconds more until revalidating it. Remember that the caching is done on server side. So, you may want to look at your server defitinitons on js files. Usually, in the deployment environment, I instruct my webserver to send cache header for *.js *.png etc. After configuring the web server for sending cache headers, it is the browser's work to take care of the rest. In that case, your browser works as expected.
You can look at RFC2616 for 304 response. You may also want to look at this decent caching tutorial. It should clear some ideas.
The problem is with Chrome. If you press Refresh button it invalidates the cache, but if you press Enter in address bar it gets the resources from cache.
In my application, I make numerous calls to preload images to brower cache in the background using Loader instances and ignore the complete event. I don't store the results in the application, but rather want to store them in the browser cache. The images have long Expires header dates.
When I want to use a particular image(s), I again use a Loader instance and call the same url and listen for the complete event to load the file to an Image.
The problem is that when I re-request the url for the "cached" image, it is making an http request with response 200 status, which I presume means it is hitting the server.
How do I make sure that a request for a cached image never hits the server from Flex?
In general, I am finding that any request to a url for a cached image (with a long expires header) is making another request to the server, or at least that is my interpretation of it in Firebug.
Any ideas how to do this? Or am I misinterpreting what Firebug is telling me?
Thanks.
So, yes I was misinterpreting firebug. It turns out that firebug logs the url request and it looks like a normal request. However, if you monitor the network with a network monitor like wireshark you will notice that there are no outgoing packets to the url for the cached images. Flex does load the cached images.
Just to be safe on the image caching, I added a the following Cache-Control header (though I think the expires is enough. One year out at the time of posting this).
Cache-Control: max-age=31536000, must-revalidate
Expires: Thu, 01 Dec 2011 16:00:00 GMT
So, if you set cache headers correctly (note that if the date is not a valid date in the expires header, it does not work), flex will load from cache when you call the url to a cached image.
Use case: user clicks the link on a webpage - boom! load of files sitting in his folder.
I tried to pack files using multipart/mixed message, but it seems to work only for Firefox
This is how my response looks like:
HTTP/1.0 200 OK
Connection: close
Date: Wed, 24 Jun 2009 23:41:40 GMT
Content-Type: multipart/mixed;boundary=AMZ90RFX875LKMFasdf09DDFF3
Client-Date: Wed, 24 Jun 2009 23:41:40 GMT
Client-Peer: 127.0.0.1:3000
Client-Response-Num: 1
MIME-Version: 1.0
Status: 200
--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="001.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
Content-type: image/jpeg
Content-transfer-encoding: binary
Content-disposition: attachment; filename="002.jpg"
<< here goes binary data >>--AMZ90RFX875LKMFasdf09DDFF3
--AMZ90RFX875LKMFasdf09DDFF3--
Thank you
P.S. No, zipping files is not an option
Zipping is the only option that will have consistent result on all browsers. If it's not an option because you don't know zips can be generated dynamically, well, they can. If it's not an option because you have a grudge against zip files, well..
MIME/multipart is for email messages and/or POST transmission to the HTTP server. It was never intended to be received and parsed on the client side of a HTTP transaction. Some browsers do implement it, some others don't.
As another alternative, you could have a JavaScript script opening windows downloading the individual files. Or a Java Applet (requires Java Runtimes on the machines, if it's an enterprise application, that shouldn't be a problem [as the NetAdmin can deploy it on the workstations]) that would download the files in a directory of the user's choice.
Remember doing this >10 years ago in the netscape 4 days. It used boundaries like what your doing and didn't work at all with other browsers at that time.
While it does not answer your question HTTP 1.1 supports request pipelining so that at least the same TCP connection can be reused to download multiple images.
You can use base64 encoding to embed an (very small) image into a HTML document, however from a browser/server standpoint, you're technically still sending only 1 document. Maybe this is what you intend to do?
Embedd Images into HTML using Base64
EDIT: i just realized that most methods i found in my google search only support firefox, and not iE.
You could make a json with multiple data urls.
Eg:
{
"stamp.png": "data:image/png;base64,...",
"document.pdf": "data:application/pdf;base64,..."
}
(extending trinalbadger587's answer)
You could return an html with multiple clickable, downloadable, inplace data links:
<html>
<body>
<a download="yourCoolFilename.png" href="data:image/png;base64,...">PNG</a>
<a download="theFileGetsSavedWithThisName.pdf" href="data:application/pdf;base64,...">PDF</a>
</body>
</html>