I have a very strange behaviour with Swagger UI v2.1.4:
When I return, from my server, my JSON document with the HTTP Content-type header "text/html", everything is fine in Swagger UI.
But when I return the same JSON document with the HTTP Content-type header "application/json", I get a "Unable to Load SwaggerUI" error in the console.
(And then in Swagger UI I have the common error message: "Can't read from server. It may not have the appropriate access-control-origin settings.".)
I have carefully checked all the details of the two HTTP responses (the working one and the failing one), and that's the only difference.
That's a pity since setting this "application/json" Content-type helps me debugging my Swagger file (because it is then displayed correctly in browsers when accessed directly).
Does anyone have an idea about how to make this "application/json" Content-type work with Swagger UI?
I solved my issue by simply removing the Content-type HTTP header: it makes my browser and my Swagger UI both happy. But I don't know if this is the most correct way to solve this problem…
Related
What is the correct format for sending an HTTP 403 forbidden message?
I'm writing a proxy in c for a homework project that has a content filtering system built in. When my proxy detects that a server's response has certain keywords that are contained in the content blacklist, I would like to send a HTTP 403 Forbidden message.
Currently, I am sending the message as: "HTTP/1.1 403 Forbidden\r\n\r\n" (without the quotes) as per this standard: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.3
When I send this message, the browser doesn't display an error and looks like it's still trying to load the page.
Are there any required header fields for this http message that I missed? Also, is this the correct usage for the 403 error? I couldn't find anything else that would be more fitting, so I chose 403 because the client won't automatically re-request the data.
Thanks in advance for any help!
For those struggling with this issue as I did, you need to make sure to close the socket or set Connection: Close as Sami noted in the comments. I assumed that you could keep it open so they could send another request with http persistent connections, but they will need to open a new connection.
As for the html displayed, you can send a body with the response (make sure you set Content-Length) that contains the html you want displayed.
Finally, here are two references, one to the HTTP response spec, and the other to the Amazon Restful response spec:
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.3
https://developer.amazon.com/docs/amazon-drive/ad-restful-api-response-codes.html
I'm using axios in my react-native app, but I can't make any POST request in android simulator/device. It always return 400 Bad Request from the server.
I've tried to set Content-Type: application/json on headers but it didn't work as well.
on postman the request works as expected.
here's the request config object:
As you know, 400 Bad Request error means that the request you sent to the website server was somehow incorrect or corrupted and the server couldn't understand it.
I think there maybe problems on your request like as wrong URL or params or header format...
PS. Axios post methods syntax is as follows:
axios.post(url[, data[, config]])
You can test any axios method here and put it into your code base after it works.
I encountered a very weird error today within phantomjs, that I'm turning to the community for. The expected JSON response of an API I was invoking with phantomJS was not being returned, but rather the result was a status of failure.
onResourceReceived() showed a 200 http status code for the resource in question
onLoadFinished() shows a status of fail
After debugging this for sometime, I noticed that the site was returning a non standard content-type header on the response. Rather than content-type of "application/json" the header being returned was "application/servicename-1.0+json".
To verify this, we spun up a local webserver that served a similar header, and sure enough phantom js cannot load the page. Setting the response header to "application/json" and phantomjs correctly renders the page and sets the page objects page.plainText variable. I've included the testing script below.
Has anyone encountered anything like this before?
Any suggestions on how to handle this issue within phantomjs?
The simplest and quickest solution I can think of (not involving editing PhantomJS' source code and compiling it) is to set up a simple local proxy server in front of PhantomJS that would rewrite the incorrect header.
It could be something like fiddler2, Charles Proxy or a simple node.js script, like this quick-n-dirty example:
// npm install proxy-tamper
var proxy = require('proxy-tamper').start({port: 3000});
proxy.tamper(/api.truelocal.com.au.*$/, function (request) {
request.onResponse(function (response) {
if ('content-type' in response.headers && response.headers['content-type'] == 'application/servicename-1.0+json') {
response.headers['content-type'] = 'application/json';
}
response.complete();
});
});
Then have PhantomJS use it:
phantomjs --proxy=127.0.0.1:3000 script.js
Note that this won't work for secure pages.
Well, after asking this question I did a deeper dive in the phantomjs source. Looks like there is some fairly strict detection on application/json here: https://github.com/Vitallium/qtwebkit/blob/phantomjs/Source/WebCore/dom/DOMImplementation.cpp#L368
I have seen previous posts about Jetty BadMessage: 400 No Host for HttpChannelOverHttp and I can confirm that I am able to repeat the problem.
I have a Jetty route in Camel Blueprint, which creates another request and forwards on to a Dropwizard service via Camel HTTP.
.process(new Processor() {
//Creates Object for request
}
.marshal(jsonFormat)
.convertBodyTo(String.class)
.setHeader(Exchange.HTTP_URI, simple(serviceEndpoint))
.setHeader(Exchange.HTTP_METHOD, constant(HttpMethod.POST))
.to(userviceEndpoint)
When this request executes, I see the following error on Dropwizard
WARN [2014-11-12 23:15:35,333] org.eclipse.jetty.http.HttpParser: BadMessage: 400 No Host for HttpChannelOverHttp#3aa99dd2{r=0,a=IDLE,uri=-}
This happens constantly, and this problem does not occur when I send a request to the DW service using SOAP-UI (using the serviceEndpoint URL).
Please if anyone has solved this problem, I would like to know how. Thank you.
Capture your network traffic, and post the HTTP request headers you are sending to Jetty.
Odds are that your HTTP client is not sending the Host: header (which is required on HTTP/1.1)
In my case, I was setting header with null value. After removing header having null value from request solved the issue.
Jetty Version: 9.3.8
I got this error when I was making a request with incorrectly formatted headers. So instead of having the header as "X_S_ID: ABC" I had "X_S_ID: ["X_S_ID":BLAH]". So the error sometimes may not literally mean you need to pass a Host header.
Fixing the headers fixed this. Print the exact request you are making and make sure all headers are correctly formatted.
Using the following code in my web api initialization I have disabled XmlFormatter so that only json is supported:
config.Formatters.Remove(config.Formatters.XmlFormatter);
Now when a client is making a request using the Accept : application/xml header it will get back json instead of XML. I find this behavior wrong. If a client asks for XML and this is not supported then it should get an UnsupportedMediaType error.
Do you know how I can achieve this in global level in my application?
By default, if Web API cannot determine a formatter using Accept or Content-Type headers, it will fall back to the first formatter that can serialize your current DTO type - and out of the box, JSON formatter is configured to work with all types, so it will always be the "last resort" fallback.
You can disable that fallback by modifying the DefaultContentNegotiator.
var config = new HttpConfiguration();
var negotiator = new DefaultContentNegotiator(excludeMatchOnTypeOnly: true);
config.Services.Replace(typeof(IContentNegotiator), negotiator);
Once you set excludeMatchOnTypeOnly to true, Web API will start to issue a 406 response (Not Acceptable) to requests for which the formatter cannot be determined - such as the one in your example. This is in line with RFC 2616 which states:
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
status codes for enabling agent-driven negotiation when the server is
unwilling or unable to provide a varying response using server-driven
negotiation.
You can find a sample VS solution here.