I'm trying to make a GET call using WSClient but for some reason the Authorization header (or any header I try to set) is not present in the request headers.
ws.url("example.com")
.addHttpHeaders("Authorization" -> s"Bearer $token")
.get()
(using play 2.8.8)
What am I doing wrong?
As #GaëlJ pointed out, I could not see the headers in Chrome devtools since it is a backend request... I was most likely looking at some random AJAX request.
Related
I keep receiving the error below when I use Ionic Serve...
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
It only occurs with "post" request. The "get" requests I have work with no error. I've seen documentation for proxy's but I was not looking to go that route. I'm currently using the CORS Chrome plugin as a workaround right now, but will be shipping to mobile soon (Ionic view) for testing, which I believe I will still run into the CORS issue using Ionic View.
I have control of the API/server - using nginx.
Any suggestions?
Cors will not affect to mobile phone. The issue is in POST method in web view. In Post methods Browser send OPTIONS Request for security Purpose. It should handle in API. I used ASP.NET WEB API When Using localhost I Used Two Methods for post in Same Name but it's not proper way for doing this. You need to handle in Configuration to Igonre this. If you have API without parameters add headers "content-type x-www-form-urlencoded" to you request header. If there are parameters. use another method without parameters using same name.(Method overloadin). But when you are using livehost don't forget to remove redundant methods.
I am using Play 2.3.7. I am using the WS client to make REST calls. I have two questions
I am setting the cookies on my request like
ws.url.withHeaders("Cookie", "cookie_name=foo")
I also want to set maxAge, domain, path, secure and httponly attributes of the cookie. Any idea of how to do this without vanilla string concat. is there an API way?
I have to do a POST with Json Content. I see that the WSClient API needs either a FILE or an Object which is serializable to json. In my case my content is already json string. so all i need to do is to post the string. (which is already json).
I don't believe there's an API for this. You'll have to build the string yourself.
Yes, just POST the JSON string and set the Content-Type header to application/json.
ws.url(url)
.addHttpHeaders("Content-Type" -> "application/json")
.post(jsonString)
See: https://www.playframework.com/documentation/2.6.x/ScalaWS#Request-with-additional-headers
I'm developing a REST API using Zend Framework 1.12.3. I would like to know whether it's possible to set a HTTP response code from inside a Handler.
I'm using the Handler to check the "Accept" header. In case the requested format type is not supported, I should set a 415 HTTP error (Unsupported Media Type). However, I'm not able to set a response code from inside the Handler.
What do you mean by handler?
You can set a response code anywhere you have access to the Response object.
Technically, you can access the Response object nearly anywhere (after Bootstrap, at least) using:
$response = Zend_Controller_Front::getInstance()->getResponse();
The set your response code using:
$response->setHttpResponseCode($code);
It's most natural to do this in controllers since each controller already has a reference to the Response object:
$this->_response
I developed a rest server, and I put it to run in localhost, and I'm trying to perform tests with JMeter, sending requests posts and gets (depends of called method).
I already send to Rest server and got result with JMeter in simple post requests, get requests, sending files with post, and sending a Json with post.
But I don't know how to send a Form-UrlEncoded object to server. My Rest server consumes application/x-www-form-urlencoded, and I need to send 3 String parameters.
There's some way to set the MimeType for every parameter and perform the test ?
I'm using Jmeter 2.7
[Update]
I solved this by disabling the option:
use multipart/form-data for post
And enabling:
redirect automatically
Instead of:
follow redirect
The parameters I put normally in the table "Send parameters with the Request" with each respective names.
For sending form parameters as application/x-www-form-urlencoded, add a header parameter Content-Type with value application/x-www-form-urlencoded.
The following steps is aplicable for Jmeter 2.3.4
Add a HTTP Header Manager under your http Request.
Add new parameter to HTTP Header Manager with name Content-Type and value application/x-www-form-urlencoded.
Uncheck "Use multipart/form-data for HTTP POST" of HTTP request.
Uncheck "Encode?" of each request parameter(not necessary).
kept "Content Encode:" text box of HTTP request as empty.
This won't work for PUT request.
For put request add parameters as path parameter and set Content-Type header then Jmeter will do by itself.
Here's the solution for HTTP POST with x-www-form-urlencoded testing with jmeter. You just folllow like these.
Go to Thread Group -> Add listener -> Views Result in table, View result Tree. To see the process of responding.
Have you tried to save your test using BadBoy or JMeter Proxy to see what your application actually sends?
To see what happens under the hood you can also use FireBug if you're using FireFox or Ctrl+Shift+i if you're on Chrome.
IllegalCharsetNameException will go immediately only after you will add the required content-type in HTTP Header Manager for HTTP request .
Hope this helps.
followed exact steps mentioned i still see an exception thrown
Response code: Non HTTP response code: java.nio.charset.IllegalCharsetNameException
Response message: Non HTTP response message: application/x-www-form-urlencoded
java.nio.charset.IllegalCharsetNameException: application/x-www-form-urlencoded
at java.nio.charset.Charset.checkName(Charset.java:315)
at java.nio.charset.Charset.lookup2(Charset.java:484)
at java.nio.charset.Charset.lookup(Charset.java:464)
at java.nio.charset.Charset.forName(Charset.java:528)
at org.apache.http.entity.ContentType.create(ContentType.java:210)
at org.apache.http.entity.StringEntity.<init>(StringEntity.java:116)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sendPostData(HTTPHC4Impl.java:1340)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.handleMethod(HTTPHC4Impl.java:592)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:409)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1166)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1155)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:475)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:418)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:249)
at java.lang.Thread.run(Thread.java:745)
I'm trying to use Jersey as a client for a RESTful application. Specifically I'd like to POST some JSON to the server and get JSON back, so my code looks like this:
final JSONObject config = new JSONObject();
clientConfig.put("fooParam", 60 * 5); /* 5 min timeout */
final JSONObject newClient = client.resource(/* URL */).
type(MediaType.APPLICATION_JSON).
accept(MediaType.APPLICATION_JSON).
post(JSONObject.class, config);
this generates the expected HTTP request with the Content-Type and Accept headers set appropriately. Now the server decides the create the requested resource and redirects there using a HTTP/1.1 303 See Other response (which is good practice as far as I know). The good news is that Jersey happily picks up the Location header and indeed requests the resource it was told to. The bad thing is that it seems to have forgot that I only wanted to get application/json resources and sends a GET with
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
which the server answers happily (with perfectly legal HTML). I verified this using Wireshark. The problem is that Jersey blows up on this as it can not parse this into a JSONObject. So my question is
Is that behaviour of Jersey correct or rather a bug?
Is there some clever way around this?
I'm aware that I could possibly go through Jersey's ClientResponse class and see if I was redirected myself, but I think there should be a better way to do this.
After a short conversation with Pavel on a Jersey mailing list, it seems as if the problem lies withing the HttpURLConnection class from the Java libraries. Working around this is easy by using the Apache HTTP Client library binding for Jersey, which works nicely.