The data sent in body data is ignored.
Bean will be created with its default data instead of the data sent via post.
Output Body :
POST http://localhost:9080/myapp/createEntity
POST data:
{
"entity.name":"name",
"entity.description":"description",
"otherEntity.name":"name"
}
Cookie Data:
......
Header :
Connection: keep-alive
Content-Type: application/json
Accept: application/json
Content-Length: 378
Host: localhost:9080
User-Agent: Apache-HttpClient/4.5.12 (Java/1.8.0_262)
Though, the request works fine with a GET :
As it is form data, the right content-type to use is : application/x-www-form-urlencoded.
Instead of using the body data, i did sent it as regular parameters. (This way, no need to care about the body data format.)
Works perfectly now !
Related
As far as I understand, POST parameters can be sent using Content-Type only either multipart/form-data or x-www-form-urlencoded. Is that right?
I want to send the parameters wrapped in JSON. Is that possible?
Will the parameters in the request
POST /login HTTP/1.1
Host: localhost:8080
Content-Type: application/json
{"username": "test","password": "test"}
be identified as username=test&password=test?
I'm trying to send json data as a response body in grails. I've tried setting the Content-Type header to application/json using the following methods:
render (status: httpServletResponse, text: responseToRender as JSON, contentType: "application/json")
Each time the resulting header is as follows:
Content-Type: application/json;charset=utf-8
How do I get rid of the charset=UTF-8 postfix?
You can not get rid of the charset postfix.
You can change it with the charset parameter defined here:
https://docs.grails.org/latest/ref/Controllers/render.html
You can also provide no information by just handing json to render, such as:
response.setContentType("application/json")
render JsonOutput.toJson(responseToRender);
However, this will default to the standard encoding required by HTTP 1.1 which is ISO-8859-1. therefore your result would be application/json;charset=ISO-8859-1
https://www.w3.org/International/articles/http-charset/index.en
So, if you somehow need to use this parameter, you may use .split(";")[0] to access only the first part.
I'm not a ruby or rails programmer, but I'm tasked with reverse engineering an API for an RoR app. My HTTP POST requests are failing a validation check, where this line is supposed to provide a specific piece of data:
value = #_request.env['HTTP_X_MY_TOKEN'];
From what little experience I have and searching I've done, it appears to be looking for an HTTP request header MY_TOKEN but I'm unsure if that's the case.
My current HTTP request looks like this:
POST /myapp HTTP/1.1
Host: website.com:80
Content-Type: application/json
Content-Length: 12
my post data
If that is the case, can I simply add it to my HTTP post request headers as follows:
POST /myapp HTTP/1.1
Host: website.com:80
Content-Type: application/json
MY_TOKEN: sometokentext
Content-Length: 12
my post data
If not, how do I fill this value during my HTTP POST request?
Sending X-MY-TOKEN should do the trick.
As a side note, prepending custom headers with X- is no longer recommended and deprecated according to RFC-6648:
Custom HTTP headers : naming conventions
I followed the example from here but I cannot get this to work!
I can't see anything wrong with the update query and I can't think of what to change because it seems fine. I'm only testing with one request because I wanted to make sure it works first.
Here's the request's body:
--batch_hJUuHcmH7ADWhYbtkF0o9JWlq
Content-Type: multipart/mixed; boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Content-Type: application/http
Content-Transfer-Encoding: binary
MERGE PrescriptionService.svc/Prescriptions(1L) HTTP/1.1
Host: 192.168.10.179
Content-Type: application/json;odata=verbose
{"PrescriptionType":"RegularMedicationPrescriptionType","Page":"0","Comment":"whoaaaaaa"}
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)--
--batch(hJUuHcmH7ADWhYbtkF0o9JWlq)--
I get a 202 Accepted so the "overall" batch request is not malformed. This is the response from the server:
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c
Content-Type: multipart/mixed; boundary=changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d
--changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d--
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c--
I tried POSTing to that same URL in the batch body to create an entity and it doesn't work either, so it has to be something with the request body.
What's wrong with the request's body?
The changeset boundary as specified in the header:
boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
must match exactly the one used later on:
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Which it doesn't. I don't know why you added the parenthesis, but they should not be there.
Same goes for the batch boundary itself.
I'm trying to implement an odata consumer, specifically right now related to doing batch operations and change sets, following the odata documentation essentially loads to this sample multipart batch that I've used as a basis.
However when I actually run this batch code (via fiddler request builder for example) updated with my own entity paths and such, I receive the following error:
Error processing batch request. At the
start of every operation, exactly two
headers need to be specified:
'Content-Type' and
'Content-Transfer-Encoding'. Make sure
these headers are present and have the
correct values.
If I remove the Content-ID from the change set the change set works correctly, but obviously the later operations no longer work because they reference this Content-ID.
I've attempted to move the Content-ID header out of the change request multipart.. part headers, and into the actual part payload request headers, ie:
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
<AtomPub representation of a new Customer>
becomes
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
Content-ID: 1
Again this no longer complains about the change set having only headers, but still the later reference the content id fails with
HTTP 404, Resource not found for the segment '$1'
The request part which references this content-id looks something like this:
--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json
.. json ..
Assume that http://example.org/test.svc is the service root.
The documentation isn't very clear really about the format of the inner request locations, so the path reference may be incorrect.
Hopefully somebody has better understood this aspect and can advise, thanks in advance.
Stephen.
Turns out you cannot refer to a change set request if the operation in this way if the operation isn't a POST, this makes sense from the aspect that only POST methods really require this reference, but it would be useful to not need this branching logic.
Importantly however the path when referencing the Content-ID should not be absolute, but instead simply:
POST $1/$links/Resources HTTP/1.1
Content-Type: application/json