I'm looking at a request, sending some json to a spring mvc app (v4). The request is sent with a Content-Type: application/json header.
On the server side, the request handler is set with automatic serialization, through a #RequestBody annotation.
Everything's peachy right until I add a backslash to one of the variables in the payload. Then the server throws a 400 bad request.
I'd like to:
keep the request payload as json
not resort to manual encoding/decoding
How to fix this?
Thanks!
Sorted.
Problem was on the client side: client code was writing-out a json string, instead of JSON.stringify()ing an object. Once that is fixed, JSON.stringify() presents the backslash correctly to the server (backslash is reserved in json for escaping).
Related
In my Logic App, I call an XML REST API using an HTTP connector. The output of the HTTP connector is displayed as Octet-Stream. But I know from my Postman call that the API returns XML.
I know how to handle this issue. I put a Set Variable component after HTTP and set the variable to the output value which is an XML this time - I don't apply any explicit transformation.
I just want to know what would cause the HTTP connector to output Octet-Stream and if there is a smarter way to handle the issue. Even I added the same headers in the Postman call to the Logic Apps HTTP, but this didn't work.
Thank you.
Logic Apps always preserves the Content-Type in a received HTTP request or response. So if your logic app receives content with Content-Type set to application/octet-stream, and you include that content in a later action without casting, the outgoing request also has Content-Type set to application/octet-stream. That way, Logic Apps can guarantee that data doesn't get lost while moving through the workflow. However, the action state, or inputs and outputs, is stored in a JSON object while the state moves through the workflow.
In a response connector you can add a header as Content-Type as application/xml
To preserve some data types, Logic Apps converts content to a binary base64-encoded string with appropriate metadata that preserves both the $content payload and the $content-type, which are automatically converted.
xml() Casts data to application/xml
Refer for converter-functions
A JavaScript client that I have no control over is sending the incorrect HTTP request headers to my Web API services. More specifically, it's using a library that is sending an incorrect OData header.
Is there any way that I can intercept the HTTP request before it hits my services? Can I add/remove/update headers or query string info?
For instance, if I receive the following HTTP header:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 2.0
I'd like to know how to modify it to the following before the OData libraries take over:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 4.0
The header isn't incorrect. Your client expects an OData v2 service and even if you did manipulate the headers, it probably won't be able to understand the response from your server.
But you could use a simple HTTP proxy to rewrite the headers if you really want to try that route.
If you do that, make sure your OData server supports the Atom format because the OData JSON format changed completely between versions 2 and 4, so there's no way that JavaScript client will understand it. The Atom format changed as well, but if the client's parser is extremely lenient, it might work.
We have a client of a ServiceStack service that cannot easily send the correct value for some request headers (such as Accept or Accept-Encoding).
Is there any mechanism in ServiceStack (or ASP.NET) that can allow the client to use query string parameters to override the value of request headers, in a generic way?
The format URL param recognized by ServiceStack is close, but it seems to not help in this specific case (the client needs to send Accept: image/png, which seems to be ignored by the format param).
Or another way to look at this, is there a way to name or annotate the properties of a GET request DTO so that ServiceStack will populate those properties with the values of request headers during deserialization? This could provide an alternative approach for solving this problem.
Why .Net WebApi don't detect the request contentType automatically and do auto-binding?
If I make a request without informing the contentType a HTTP 500 error occour:
No MediaTypeFormatter is available to read an object of type 'ExampleObject' from content with media type ''undefined''.
why not try to detect the incoming data and bind automatically?
Another case:
This request with Content-Type: application/x-www-form-urlencoded send a JSON:
User-Agent: Fiddler
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: localhost:10329
Content-Length: 42
Request Body:
{"Name":"qq","Email":"ww","Message":"ee"}:
My Action don't detect the JSON request data automatically in object param:
public void Create(ExampleObject example) //example is null
{
{
Instead of letting the object null why they do not try to solve it?
Then, for the binding occurs I need to send with Content-Type: application/json.
It would be best if .Net WebAPI detects the type of request data and do a auto-binding? Why not in this way?
application/x-www-form-urlencoded means you will be sending data in the x-www-form-urlencoded standard. Sending data in another standard will not work.
Sounds like what you want to do is accept multiple formats from the server.
the way http works is that the client makes a request to the server for a resource and tells the server what content types it understands. This means that the client doesnt get a response it isnt able to decode, and the server knows which responses are more appropriate on the client. For example if you are a web-browser the most appropriate content type is text/html but if you get XML you can probably do something with that too. So you would make a request with the following:
accept: text/html, application/xml
this says you prefer html but also understand XML
In your example if your client wants application/x-www-form-urlencoded but can also deal with JSON then you should do the following when making a request
accept: application/x-www-form-urlencoded, application/json
For more details see the HTTP Spec on accept headers here http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
You may also want to create a new media type formatter so your server knows how to give clients application/x-www-form-urlencoded, take a look at this blog post for more info on how to do this http://www.strathweb.com/2012/04/rss-atom-mediatypeformatter-for-asp-net-webapi/
For requests not sent by HTML forms, does HTTP limit the Content-Type of a request to application/x-www-form-urlencoded for non-file uploads, or is that MIME type "right"/standard/semantically meaningful in any other way?
For example, PHP automatically parses the content into $_POST, which seems to indicate that x-www-form-urlencoded is expected by the server. On the other hand, I could use Ajax to send a JSON object in the HTTP request content and set the Content-Type to application/json. At least some server technologies (e.g. WSGI) would not try to parse that, and instead provide it in original form to the script.
What MIME type should I use in POST and PUT requests in a RESTful API to ensure compliance with all server implementations of HTTP? I'm disregarding such technologies as SOAP and JSON-RPC because they tunnel protocols through HTTP instead of using HTTP as intended.
Short Answer
You should specify whichever content type best describes the HTTP message entity body.
Long Answer
For example, PHP automatically parses the content into $_POST, which seems to indicate that x-www-form-urlencoded is expected by the server.
The server is not "expecting" x-www-form-urlencoded. PHP -- in an effort to make the lives of developers simpler -- will parse the form-encoded entity body into the $_POST superglobal if and only if Content-Type: x-www-form-urlencoded AND the entity body is actually a urlencoded key-value string. A similar process is followed for messages arriving with Content-Type: multipart/form-data to generate the $_FILES array. While helpful, these superglobals are unfortunately named and they obfuscate what's really happening in terms of the actual HTTP transactions.
What MIME type should I use in POST and PUT requests in a RESTful API
to ensure compliance with all server implementations of HTTP?
You should specify whichever content type best describes the HTTP message entity body. Always adhere to the official HTTP specification -- you can't go wrong if you do that. From RFC 2616 Sec 7.2.1 (emphasis added):
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and
only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
Any mainstream server technology will adhere to these rules. Thoughtful web applications will not trust your Content-Type header, because it may or may not be correct. The originator of the message is free to send a totally bogus value. Usually the Content-Type header is checked as a preliminary validation measure, but the content is further verified by parsing the actual data. For example, if you're PUTing JSON data to a REST service, the endpoint might first check to make sure that you've sent Content-Type: application/json, but then actually parse the entity body of your message to ensure it really is valid JSON.