I have been troubleshooting an error on my web app and have concluded that Chrome is failing to handle my http request when my headers get too large.
Why are my headers large?
I am using a JWT authorization scheme that includes permissions in the JWT token. With my admin account that token is growing as I have permissions for each tenant. The JWT is currently around 5200 characters.
Why do I blame chrome?
I have tested the identical request in several environments:
Swagger: fails with TypeError: Failed to fetch
Postman Chrome Extension: fails with Could not get any response
Postman Native App: Succeeds
Python script using requests: Succeeds
curl: Succeeds
For each test I have the same headers, url, and body (none because it is a GET).
Notes
While researching this, I came across this SO Question which suggests that Chrome is limited to 250KB headers. Mine are under 6k.
If I use a smaller Authorization header, then Swagger and the Postman Chrome Extension both succeed.
Bottom line:
Can we confirm my conclusion that Chrome is having trouble with the larger header?
What can I do about that?
Related
I am trying to make connection to Azure VSTS with SOAPui through vsts rest api's, but the response I am getting is: HTTP/1.1 203 Non-Authoritative information
Though when I hit the same request from POSTMAN it's giving successful response for every operation(Get, Post, Delete).
As I have a framework for API automation in SOAPUI I need to have this connection to post the test results in VSTS against respective test case.
Any idea how to resolve this would be much appreciated!!
Thanks
This is due to the incorrect authentication headers (Authorization header) that you send in the request. I have experienced this issue when you are trying to send empty username in SoapUI - Basic Authorization tab.
This can be handled by generating the header offline (using some online utilities - https://www.blitter.se/utils/basic-authentication-header-generator/) and sending in a separate header like below,
Authorization: Basic Onl1eWl1eWl5aXlpeWl5aXk=
Hope this helps.
I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.
I am facing the issue in calling the OneDrive for Business API to work. Below are the steps I have followed till now:
Created a Web App/API application in Microsoft Azure Portal (A very tricky process). Gave all the permissions.
Got Application ID (A_ID) from there.
Went to the URL to get the 'code' via browser:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=<A_ID>&redirect_uri=<URI>
Got the code. Did a callout via POSTMAN (using the code, client ID, client secret and redirect URI) to the URL: https://login.microsoftonline.com/common/oauth2/token
Received an Access Token (AT) and other details.
NOW, when I want to use this AT to upload a file, I am getting the error. The URI is: https://<tenant>/_api/v2.0/me/drive/root:/Abc.txt:/content. For headers, I am passing: Authorization-> Bearer AT; Content-Type -> application/octet-stream
The error is:
{"error":{"code":"unauthenticated","message":"Token contains invalid signature.","innerError":{"code":"invalidSignature"}}}
I don't know where the issue is. Is it in the tenant name I am using (There is a chance that I might be using it wrong!) OR is it in the permissions OR I have not set up the app in the Azure Portal correctly OR is it something entirely different.
I am getting a 401 and some cross domain issues when trying to access IBM Weather REST API from either client (browser) or server.
If I generate a URL and try and access it directly from a browser (eg paste it in it works fine and the JSON weather report is returned).
When I try and run the Javascript HTTP request from either the browser or server it seems like it's only allowed to run from an ibm.com domain.
Failed to load https://twcservice.au-syd.mybluemix.net/api/weather/v1/geocode/-33.00/151.00/forecast/daily/7day.json?units=m&language=en-US: The 'Access-Control-Allow-Origin' header contains multiple values 'https://*.ibm.com, https://*.ibmcloud.com', but only one is allowed. Origin 'http://localhost:3000' is therefore not allowed access.
I am using the free service on Bluemix. Is this restricted to only run via a Bluemix server? or are there some options I can pass when I create the service on Bluemix
Note, when I make the request I am using the credentials supplied via the Bluemix console. Again, this works via the browser URL bar, but not via code.
Update/More info: if I hit past the URL above into the browser (with creds) it works as above, then if hit it via the web app in the same session it works.
Hmmm. So the IBM server is sending the following response header:
Access-Control-Allow-Origin: https://*.ibm.com, https://*.ibmcloud.com
That's an invalid response from IBM. Unfortunately, I think your only option is to complain to IBM, and convince them to
Return a valid Access-Control-Allow-Origin response header (with only one value)
Allow people outside of IBM to access it
Without that, I fear you're out of luck.
Initial Context:
We're developing Web Aplication Server and deploying it in Payara Server 4.1.2.173. The mininal stability testing are passing perfect and MVP works perfectly but in order to improve the performance testing of the system we have created different test case in JMeter (3.2) that simulates Front-End normal activity and make all the necessary requests to the server.
The problem:
When JMeter starts making request REST(JAX-RS) everything works fine but suddenly some requests (users) return the following error response:
<h1>HTTP Status 401 - Unauthorized</h1>
<hr/>
<p>
<b>type</b> Status report</p><p>
<b>message</b>Unauthorized</p><p>
<b>description</b>This request requires HTTP authentication.</p>
<hr/>
It's very strange because the error appears randomly and apparently it is not because of concurrency problems.
Any ideas what might be the issue? Thanks
After a few research I've discovered that JMeter has some difficulties to add dynamic header token to Http request when volume Thread request are increasing. In my scenario I was doing the following:
Making a HTTP Login request
Generating token session in Server
JMeter gives the token from the response and I apply post-processor to encode it to Base64 and save to JMeter system variables.
In the next HTTP request I add the token in HTTP Header configuration component as a Basic Authorization.
When the amount of Threads increase (150 approx) Server return error 401. Despite of JMeter shows as if the token are included in header, there is no sign of it in the real request. The behaviour appears randomly and with no common reason...
Solution:
We have decided to add token session as a part of CSV Data set - configuration file and JMeter is capable of manage all requests without any rare 401 error.