I got this Java code at my RESTFul Web Service:
Response response = Response.ok().
entity(method(paramether)).
header("Access-Control-Allow-Origin", "*").build();
I want to add some header that lets me set the charset to UTF-8 through the HTTP itself (because I'm facing some problems when trying to set only at the document). Thanks in advance.
Content-Type, e.g.:
Content-Type: text/html;charset=UTF-8
The Content-Type header can be used to specify the type of the content you return, along with it's character set.
As an example:
Content-Type: text/html; charset=utf-8
Taken from the Wikipedia article on HTTP headers https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Related
I am trying to parse a request body where
Content-type: application/vnd.contentful.management.v1+json
When I give Content-type: application/json
it works fine but Contentful CMS passes the above content-type so I have to parse this somehow.
Seems that you are using the contentful Java SDK right ?
That header is filled by the SDK, is there a reason that you need to parse that header ?
I found the solution.
If the body is of type json it by default look for Content-type application/json in header.
To avoid the validation of the Content-Type header is JSON I used this and it worked.
#BodyParser.Of(BodyParser.TolerantJson.class)
I'm trying to extract some information from raw HTTP Request messages (like the one below) and store them into instances of the org.apache.http.message.BasicHttpRequest (https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/index.html) class.
I was able to employ org.apache.http.message.BasicLineParser class and its method parseHeader(String value, LineParser parser) to process (parse + store) the headers, but I don't know how to deal with the parameters passed with the form.
POST https://gist.github.com:443/gists HTTP/1.1
Host: gist.github.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,fr;q=0.8,it-it;q=0.6,it;q=0.4,en-us;q=0.2
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://gist.github.com/
Connection: keep-alive
Content-Type: multipart/form-data; boundary=-------------------------10314229756379422411656878663
Content-Length: 1242
-----------------------------10314229756379422411656878663
Content-Disposition: form-data; name="parameter_name"
parameter_value
Do you know an utility which can parse the content starting after the header above (i.e. after the first empty line)? What I am interest in collecting are all the pairs <"parameter_name","parameter_value"> present in the request body.
I have already read similar answers/questions such as Parsing raw HTTP Request but I did not find anything helpful on the form-data component
Thanks in advance for your help and time
What you are seeing is MIME encoded content body. HttpClient is content agnostic and therefore does not provide a means of parsing such content. One can however use Apache Mime4J to do so.
I'm attempting to use the Tumblr API in an Android app to authorize users and make text and photo posts. I'm using the Scribe library. So for, I can successfully obtain an access token and use it to get user info. I can also make text posts without any issues. This tells me that I'm signing requests correctly.
However, I've spent the last week and a half attempting to make photo posts without success. I continuously receive 401 errors (Not Authorized) I've read through many posts on the Tumblr support forum as well as here on Stack Overflow, but was unable to find a solution.
I'm reluctant to include the Jumblr library because I'm trying to keep my app as lean as possible. That said, I reviewed the Jumblr code and decided to mimic how photo posts are sent (https://github.com/tumblr/jumblr/blob/master/src/main/java/com/tumblr/jumblr/request/MultipartConverter.java). I'm still receiving the exact same error.
Below is an example my multipart POST request and the response I receive. I've replace the blog name, and OAuth signature, consumer key, and token variables, and have removed the binary image data for brevity sake. Everything else is untouched. I have a few questions...
Are there any other variables that should be included in the
multipart section? A Stack Overflow user stated that placing the
"oauth_" signature variables in there fixed his problem. I didn't
have success with this, but maybe there was something I was missing.
The Jumblr app doesn't appear to do any encoding of the image data,
although the Tumblr documentation states that it should be URL
encoded. Right now I'm sending it as the Jumblr app appears to (raw
binary). Is this correct?
Does anything else in my request look
incorrect?
REQUEST:
NOTE: I learned that the OAuth signature should be generated WITHOUT the multipart form. My code takes that into account when building this request!
POST http://api.tumblr.com/v2/blog/**REMOVED**.tumblr.com/post HTTP/1.1
Content-Type: multipart/form-data, boundary=cbe6b79db1b3cbe6b79e104e
Authorization: OAuth oauth_signature="**REMOVED**", oauth_version="1.0", oauth_nonce="3181201716", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="**REMOVED**", oauth_timestamp="1388791537", oauth_token="**REMOVED**"
Content-Length: 1001
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.3; SM-N900T Build/JSS15J)
Host: api.tumblr.com
Connection: Keep-Alive
Accept-Encoding: gzip
--cbe6b79db1b3cbe6b79e104e
Content-Disposition: form-data; name="type"
photo
--cbe6b79db1b3cbe6b79e104e
Content-Disposition: form-data; name="caption"
Another pic test...
--cbe6b79db1b3cbe6b79e104e
Content-Disposition: form-data; name="data[0]"; filename="postr_media_file_1388791537-1709648435.jpg"
Content-Type: image/jpeg
---- BINARY DATA REMOVED FOR BREVITY ----
RESPONSE:
HTTP/1.1 401 Not Authorized
Server: nginx
Date: Fri, 03 Jan 2014 23:25:39 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: close
Set-Cookie: tmgioct=52c746f34266840643527780; expires=Mon, 01-Jan-2024 23:25:39 GMT; path=/; httponly
P3P: CP="ALL ADM DEV PSAi COM OUR OTRo STP IND ONL"
3c
{"meta":{"status":401,"msg":"Not Authorized"},"response":[]}
I posted the answer in the "Tumblr API Discussion" Google Group. This is what I did:
The key to doing it correctly is NOT just signing without the multipart form!!! Here are the steps...
Add all fields EXCEPT the data field as regular url encoded POST
body variables
Sign the request
Remove ALL off the post variables you just added from the request
Add the multipart form, including the data field this time
Some things to consider...
The Content-Type in the header should be "multipart/form-data"
The Content-Disposition of all form parts should be "form-data" and, of course, include a valid "name" attribute (ie. type, caption, etc...)
The Content-Disposition of the data part should also include a "filename" attribute
The only form part that should contain a Content-Type is data, and it should be set to the mime type of the file you are uploading (ie. "image/jpeg")
I used "data[0]" as the name of the data field. I haven't tested this with just "data", but according to everything I've read it should work that way as well. If you are creating a photo set, I believe you simple add additional parts (ie. data1. data[2], etc...). Again, I haven't tested anything except "data[0]", so do your due diligence!!!
I did NOT encode the binary image data!!! I saw people spending considerable amount of time on this in other posts when adding the image as a POST body variable. If doing this as a multipart form, you can skip the encoding and send raw binary data! ;-)
I hope this helps someone! I've spent two weeks banging my head on random solid objects trying to figure this out. The implementation is very easy to do, but there is zero documentation available on how exactly to build POST requests for photos properly. The official docs really should include that. If I had know what I just posted above I could have completed this in minutes instead of weeks!!!
The last request I posted earlier is still valid, but here it is again. Just remember what I mentioned about the signature!!!
REQUEST:
POST http://api.tumblr.com/v2/blog/REMOVED.tumblr.com/post HTTP/1.1
Content-Type: multipart/form-data, boundary=c60f7c041c02c60f7c046e9b
Authorization: OAuth oauth_signature="***REMOVED***", oauth_version="1.0", oauth_nonce="315351812", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="***REMOVED***", oauth_timestamp="1388785116", oauth_token="***REMOVED***"
Content-Length: 1001
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.3; SM-N900T Build/JSS15J)
Host: api.tumblr.com
Connection: Keep-Alive
Accept-Encoding: gzip
--c60f7c041c02c60f7c046e9b
Content-Disposition: form-data; name="type"
photo
--c60f7c041c02c60f7c046e9b
Content-Disposition: form-data; name="caption"
Another pic test...
--c60f7c041c02c60f7c046e9b
Content-Disposition: form-data; name="data[0]"; filename="postr_media_file_1388785116-1709648435.jpg"
Content-Type: image/jpeg
***** BINARY DATA REMOVED FOR BREVITY *****
--c60f7c041c02c60f7c046e9b--
I am using Java with Jersey 2.0 client to make a REST call to the paypal REST API. According to the API doc, I should be making a post to: https://api.sandbox.paypal.com/v1/oauth2/token with the Accept: application/json and Accept-Language: en_US. It also indicates that I should pass in the body grant_type=client_credentials. I do all this but I keep getting a 406 or 415. What I can't figure out is what the Content-Type of the post call should be? I've tried text/plain, text/html, application/json, form-url-encoded.. nothing seems to get me a token back. Not sure why their API doc writer didn't include the Content-Type and format of the payload in the documentation. Anyone know what the Content-Type should be for the body of the post?
I'd like to add that when I do any Content-Type other than form-url-encoded, I get back 415, which means mediatype not accepted, however when I pass in anything using form-url-encoded, I get back the 406, which basically tells me the body is not acceptable.
Thanks.
Thanks for bringing up the question.
There was a recent change in the /token call and requests for an access token need to have the content-type set as application/x-www-form-urlencoded. This is done by default in cURL calls.
Updated docs that include a note about this will be going out very soon.
Inbound the OAuth 2 endpoint only accepts "application/x-www-form-urlencoded" or it will throw a 415, the payload then needs to be properly url encoded. Likewise the accepts header needs to contain "application/json", or the service will throw a 406.
For example:
Headers:
Authorization: Basic [base64 encoded]
Content-Type: application/x-www-form-urlencoded
Accepts: application/json
Payload sample:
grant_type=client_credentials&response_type=token
Hi I have a client that is trying to POST to us with the following http headers:
content-type: application/x-www-form-urlencoded
content-encoding: UTF-8
But our web application firewall keeps picking them up and throwing error:
Message: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "45"] [id "340362"] [msg "Atomicorp.com WAF Rules: ModSecurity does not support content encodings and can not detect attacks using it, therefore it must be blocked."] [severity "WARNING"] Access denied with code 501 (phase 2). Match of "rx ^Identity$" against "REQUEST_HEADERS:Content-Encoding" required.
Action: Intercepted (phase 2)
Anyone would like to shed some light into this matter?
It is invalid. The content-encoding specifies the data transfer encoding used by the issuer of the content. UTF-8 is not a content encoding, it is a character set. Specifying the character set is done in the content-type header:
content-type: text/plain; charset=utf-8
Valid content-encoding values are, for instance, gzip, deflate. An HTTP client should specify what content encoding it supports with the accept-encoding header; the HTTP server will reply with a content-encoding header.