Setting Content-Type='application/json' in header is no longer working in tests as of 2.2.0

[Andy Kennealy]

Hello,

I saw there's been some great fixes and enhancements the past few months! So I've decided to move up to the latest version (2.3.0), but ran into an issue.

I think I've narrowed it down to a fix in 2.2.0 for: 

Fixed an issue with content-type identification when passing in content-type header manually using a header.

I'm wonder what the issue was? Things were working for me until I upgraded to 2.2.0. It may be an issue on my end -- I may need to tweak the way I write my tests, our api, etc.

I started writing my tests in 1.8.1 as i.e.:

        final RequestSpecification request = given().

                header("Content-Type", "application/json").

                body("{foo:bar}");

        final ResponseSpecification response = expect().

                ....

        given(request, response).post("resource/loc);

This was working great until I moved up to 2.2.0. I now get an unsupported media type from our api:

Request method: POST

Request path: https://myresource

Request params: <none>

Query params: <none>

Form params: <none>

Path params: <none>

Headers: Content-Type=application/json

Cookies: <none>

Body:

{foo:bar'}}

HTTP/1.1 415 Unsupported Media Type

Server: nginx/0.7.67

Date: Fri, 24 Jan 2014 21:34:32 GMT

Content-Type: application/json;charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

Set-Cookie: JSESSIONID=app-37gz27w6gckapgujztyzdu2fr.app-3;Path=/

Expires: Thu, 01-Jan-1970 00:00:00 GMT

{

    "meta": {

        "success": false,

        "status": 415,

        "error_code": "invalid_content_type",

        "error_desc": "Resources must be sent with Content-Type='application/json' header."

    }

}

To Note: In 1.8.1, I had to manually specify the content-type in my header, or else I would get the same error as below. 

[Johan Haleby]

Hi, 

Looks like an issue. Please add it to the issue track and I'll see what I can do.

Regards,

/Johan

--
You received this message because you are subscribed to the Google Groups "REST assured" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rest-assured...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Johan Haleby]

Is the problem that the charset is added in the charset automatically? Servers ought to be able to cope with this.

[Johan Haleby]

Sorry, I mean "Is the problem that the charset is added in the content-type automatically?"

[Andy Kennealy]

Sorry but there's no way to enable more detailed logging afaik (perhaps you could configure the underlying http client instance though). Perhaps you could use wireshark to see exactly what's sent on the wire then we'd know exactly what has changed?

/Johan

On Mon, Jan 27, 2014 at 3:32 PM, Andy Kennealy <andy...@gmail.com> wrote:

Hi Johan,

I've compared the working request from 1.8.1 to the failing request in 2.2.0 and they look identical -- both having charset automatically added to the content type.

Is there a verbose mode I can set in Rest Assured to see more in the logs?

[Andy Kennealy]

Thanks Johan.

I may try out wireshark when I get some time, but for now, I'm going to go back to a rest assured 1.8.1

[Johan Haleby]

Thanks. It's very important that you help out with this otherwise there's no way I can fix it since I can't reproduce it.

On Mon, Jan 27, 2014 at 9:13 PM, Andy Kennealy <andyke...@gmail.com> wrote:

Thanks Johan.

I may try out wireshark when I get some time, but for now, I'm going to go back to a rest assured 1.8.1

--

[Andy Kennealy]

I understand. I can also try and reproduce the issue with a public api.

I was just hoping to see exactly what's changed in 2.2.0, regarding passing the content-type header manually using a header. As this was mentioned in the change log as a fix.

[Johan Haleby]

If you could reproduce it with a public API that would be really good.