when I try to Respond with on HTTP 204 Status, my Chrome browser is starting an Download that fails.
Request:
Request URL: https://dummy.page/dummyRequest
Request Method: GET
Status Code: 204
Remote Address: [dummy]:443
Referrer Policy: no-referrer-when-downgrade
Response:
date: Fri, 08 Mar 2019 08:24:05 GMT
server:
status: 204
When I use Dev-Tool to inspect the response, chrome says "faild to load response data" and in firefox I can see one empty line.
My server returns a Response via Java:
return Response.noContent().build();
I also tried to return NULL at this point but that did not change anything.
The whole thing is working fine in Firefox but when I try in Chrome it starts an Download of "dummyRequest" (from the URL) which fails.
So what I want to know: why is Chrome starting a download and what could I do against?
Thanks for helping ;)
I came across the same issue with 204 responses. What worked for me was checking the Content-Type response header on the server-side before sending the response.
My 204 responses were sending a default Content-Type of application/octet-stream (from the link: "An unknown file type should use this type. Browsers pay a particular care when manipulating these files"). When switching the Content-Type to something different (I chose text/html), the trigger for downloads stopped.
Related
Attempting to make a POST request I am getting the following response:
HTTP/1.1 408 Request body incomplete
Date: Tue, 19 Jul 2022 07:53:39 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache, must-revalidate
Timestamp: 09:53:39.074
The request body did not contain the specified number of bytes. Got 62.913, expected 116.798
The error is not shown on Chrome's console, it was found using Fiddler.
I can safely say that the service is proven not to be the cause of the issue because it has been installed on different servers and it has always worked, but if it can help track down the problem, here's the call
var postJson = function (url, parameters) {
forceDateToIsoStringparameters)
var deferred = $.Deferred();
var ajax = $.ajax({
type: 'POST',
url: url,
data: parameters)
dataType: 'json'
}).done(function (data) {
deferred.resolve(data);
}).fail(function (error) {
deferred.reject(error);
});
return deferred.promise(ajax);
};
Server settings:
The service that fails is hosted on IIS 8 and has been moved from one server to another with HTTPS protocol set up.
It has been working perfectly on the previous server but currently, making some requests that are apparently too large, returns "error 408" responses on some computers via HTTPS.
The server has two separate bindings on the same IP and port (443), with two different certificates linked to two different host names.
Server bindings
Furthermore, we increased the request limit size in IIS to one that exceeds that of the body of the failing request.
IIS config
Client settings:
No difference has been found between the PCs where the service responds and others where it doesn't. Both systems run Windows 10 and the connection was performed on Chrome (even in incognito mode).
The request body was identical both on working and not working PCs and with the same exact size (116798)
On not working PCs, it has been possible to make the call succeed by reducing the size of the body; but we don't understand what setting, either on the server or client-side (PC, router, etc), could cause this behavior
Edit:
After some tests, it appears the problem does not happen with Edge, something in Chrome is truncating the ajax request
Try to annotate content-length:116.798 in the header, because there is an error in the server-side length check. If the content-length length is smaller than the actual length, there will be no error, but if the content-length length is larger than the actual length, an error will be reported, resulting in the verification failure.
I'm creating a HTTP Web API where some of my resources will be cacheable. A cacheable resource will have two operations, GET & PUT. The GET will return response headers of Cache-Control: public,max-age=3600 & Etag: "2kuSN7rMzfGcB2DKt67EqDWQELA". The PUT will require the If-Match header which will contain the Etag value from a GET of the same resource. My goal is to have the browser cache invalidate a resource when I PUT to that resource. This works fine until I add the If-Match header to the PUT request. When the PUT request contains the If-Match header, subsequent GET requests will fetch from the cache which would be stale data. This is the behavior I've been experiencing with Chrome. Firefox doesn't behave like this, and works as I assume it should. Is this a bug in Chrome or am I misunderstanding some part of the HTTP spec?
Here are some example requests to show behavior:
//correctly fetchs from origin server (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
//correctly fetchs from disk cache (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
//correctly updates origin server (returns 200)
PUT http://localhost/api/my-number/1
Request Headers
if-match: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Request Body
8
//incorrectly still fetches from disk cache (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
This is indeed incorrect behavior. RFC 7234 says:
A cache MUST invalidate the effective Request URI... as well as the URI(s) in the Location and Content-Location
response header fields (if present) when a non-error status code is
received in response to an unsafe request method.
Given that, the bug report you filed looks appropriate to me.
i am facing issue where in Chrome is making multiple Rest Get calls ( not immediately but after some delay), even when i requested only once. this is not happening in other browsers, seems to be specific to Chrome.
The Rest Get call i am working will returns audio or video file and it plays in browser. when audio and video is playing, chrome is making other call and the server is throwing broken pipe exception. below is info as i see from Chrome developer Tools
General Data
Request URL:http://localhost:6390/x/y/MP3
Request Method:GET
Status Code:200
Remote Address:[::1]:6390
Referrer Policy:no-referrer-when-downgrade
Request Headers
Accept:*/*
Accept-Encoding:identity;q=1, *;q=0
Accept-Language:en-US,en;q=0.8,te;q=0.6
Connection:keep-alive
Host:localhost:6390
Range:bytes=0-
Response Headers
Cache-Control:max-age=31536000, public
Content-Length:27133142
Content-Type:audio/mpeg
Date:Mon, 22 May 2017 01:00:31 GMT
Expires:Mon, 21 May 2018 21:00:31 GMT
if we look at the content-length of the response on first call, it is almost 25 mb file, but only downloading around 5.3mb file, and when audio/video is playing for downloaded file, Chrome is making additional call even when the response code is 200 first call.
Here is info from 2nd Call even when i have not requested. it is called by Chrome automatically
General Info
Request URL:http://localhost:6390/x/y/MP3
Request Method:GET
Status Code:200
Remote Address:[::1]:6390
Referrer Policy:no-referrer-when-downgrade
Request Headers
Accept:*/*
Accept-Encoding:identity;q=1, *;q=0
Accept-Language:en-US,en;q=0.8,te;q=0.6
Connection:keep-alive
Host:localhost:6390
Range:bytes=5421245-
Response Headers
Cache-Control:max-age=31536000, public
Content-Length:27133142
Content-Type:audio/mpeg
Date:Mon, 22 May 2017 01:20:07 GMT
Expires:Mon, 21 May 2018 21:20:07 GMT
2nd request have bytes header with range. why is chrome making second call with range header even when first request i am sending complete content and response code of 200. i am under impression that unless i use Bytes Header with 206, browser should not make additional call.
i have checked many threads on why chrome is making additional calls, but they dont seem to fall into issue i am facing.
please help me on why i am facing this issue on chrome, any pointers would be helpful.
my Stack is Spring Boot, Spring Rest and Tomcat server
I am trying to do a POST in jmeter with a json as the body data but I just get a 400 back. The URL I am sending to only accepts json. I have used the same curl in Postman and it worked just fine. I have tried putting the json in the parameters as a value with no name and that didnt work.
I am just trying to send {"uid":"jmtest","name":"newdevice"}.
Sorry I cant post more links.
The sampler result is
Thread Name: QA test 1-1
Sample Start: 2016-05-11 11:50:19 MDT
Load time: 86
Connect Time: 51
Latency: 86
Size in bytes: 282
Headers size in bytes: 244
Body size in bytes: 38
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 400
Response message: Bad Request
Response headers:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Wed, 11 May 2016 17:50:19 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 38
Connection: keep-alive
X-Request-Id: 88339ee9-b74f-4e22-b581-e3124949d067
X-Runtime: 0.030877
HTTPSampleResult fields:
ContentType: application/json; charset=utf-8
DataEncoding: utf-8
And the request looks like
/url redacted
POST data:
{"devices":{"uid":"jmtest","name":"newdevice"}
[no cookies]
Request Headers:
Connection: keep-alive
Accept: application/vnd.moneydesktop.v2+json
Content_Type: application/json
MD-SESSION-TOKEN: redacted
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Host: redacted
User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_72)
The response data is
{
: "status":"400",
: "error":"Bad Request"
}
To send a POST HTTP Request with the JSON Data inside the body, need to add,
HTTP Header Manger into your request and set the name as 'content-type' and value as 'application/json' this will attached into HTTP request header and what ever the data inside your request body will send as json format.
Image 1:Set HTTP Header Manager,
Image 2:Set HTTP Request Body Data
Make sure your HTTP Header Manager is configured to send Content-Type header with the value of application/json
Given you have samplers like "home page" and "login" it might be the case you're missing HTTP Cookie Manager
The most straightforward way to see what's wrong is to capture requests sent by Postman (whatever it is) and JMeter by a sniffer tool like Wireshark, identify the differences and configure JMeter accordingly.
Finally, it looks like you're using some developer snapshot so approach to pass JSON payload as 1st argument without name might not work. Try switching to "Body Data" instead.
If above steps won't help update your question with screenshots of View Results Tree listener (all 3 tabs) and Postman
Check out Testing SOAP/REST Web Services Using JMeter for more tips.
This solution from Dmitri T, really worked for me.
Make sure your HTTP Header Manager is configured to send "Content-Type" header with the value of "application/json".
I have faced the same issue and it was resolved by setting the value of Content Encoding to utf-8 in http request. Please try.
First thing you might wanna do is put the payload inside "Body Data" Instead of "Parameters"
Then, add a config element "HTTP Header Manager"
And add a parameter "content-type" With corresponding value "application/json"
Now hit. Should do!
I figured out my problem. I had set Content_type instead of Content-Type so it was creating two content type headers.
Though Hasiya explain really well but missed how to find http request.
If you chose http default will not see method option .
I had given HTTP/1.1 415 Unsupported Media Type
After deleting space before of HTTP Header Manager ,It got 200 and worked like a charm
You must use body data, not parameters. cut and paste it the next tab on your request. Also you should change implementation to Java and check if your token is valid. Finally check your results from view results tree reporting item. It must be work for you.
In addition to many said above, make sure that the copy/paste of Accept, Content-Type from website doesn't have a trailing space! It costs me many hours to figure it out. Just a caution.
Just edit to add that if that mistake happens, return code is 415: Unsupported Media Type
Insert your json in body data field.
In your HTTP Header Manager set the headers stores to:
"name" : Content-Type
"value": application/json
Yes, we need to pass the Content-Type header.
I faced the same issue and it took nearly a day to figure out until I came across this link - https://www.blazemeter.com/blog/performance-test-web-services
Header:
Name: Content-Type Value: application/json;charset=utf-8
If none of the abovementioned solutions work for you (as it was for me) take a second look at the HTTP Header Manager. I had empty header line there
Removing it solved the problem
I was facing the similar issue, the size of my request body was also huge so along with updating content-type as application/json, i gave content encoding as utf-8 and it worked perfectly fine.
As per your attached pic , You have pasted the request in queryparameters , the payload must be in body part
check the screenshot you have payload in queryParam section
Setting the HTTP header manager fixed the issue for me
HTTP Header Manager:
Name: Content-type and Value: application/json has resolved issue.
I have a web page that returns the following header when I access material:
HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1
Pragma: no-cache, no-store
Expires: -1
Connection: close
Using a chrome extension, I want to modify this response header so that the material is actually cached instead of wasting bandwidth.
I have the following sample code:
chrome.webRequest.onHeadersReceived.addListener(function(details)
{
// Delete the required elements
removeHeader(details.responseHeaders, 'pragma');
removeHeader(details.responseHeaders, 'expires');
// Modify cache-control
updateHeader(details.responseHeaders, 'cache-control', 'max-age=3600;')
console.log(details.url);
console.log(details.responseHeaders);
return{responseHeaders: details.responseHeaders};
},
{urls: ["<all_urls>"]}, ['blocking', 'responseHeaders']
);
Which correctly modifies the header to something like this (based on the console.log() output):
HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: max-age=3600
Connection: close
But based on everything I have tried to check this, I cannot see any evidence whatsoever that this has actually happened:
The cache does not contain an entry for this file
The Network tab in the Developer Console shows no change at all to the HTTP response (I have tried changing it to even trivial modifications just for the sake of ensuring that its not a error, but still no change).
The only real hints I can find are this question which suggests that my approach still works and this paragraph on the webRequest API documentation which suggests that this won't work (but doesn't explain why I can't get any changes whatsoever):
Note that the web request API presents an abstraction of the network
stack to the extension. Internally, one URL request can be split into
several HTTP requests (for example to fetch individual byte ranges
from a large file) or can be handled by the network stack without
communicating with the network. For this reason, the API does not
provide the final HTTP headers that are sent to the network. For
example, all headers that are related to caching are invisible to the
extension.
Nothing is working whatsoever (I can't modify the HTTP response header at all) so I think that's my first concern.
Any suggestions at where I could be going wrong or how to go about finding what is going wrong here?
If its not possible, are there any other ways to achieve what I am trying to achieve?
I have recently spent some hours on trying to get a file cached, and discovered that the chrome.webRequest and chrome.declarativeWebRequest APIs cannot force resources to be cached. In no way.
The Cache-Control (and other) response headers can be changed, but it will only be visible in the getResponseHeader method. Not in the caching behaviour.