lilinkevin / rest-assured

Automatically exported from code.google.com/p/rest-assured
0 stars 0 forks source link

RestAssured.responseContentType() does not set the Accept header #349

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
 Run a test that looks like:
    private void acceptHeaderNotSet() {
        RestAssured.config = newConfig().sslConfig(sslConfig().relaxedHTTPSValidation());
        RestAssured.responseContentType(ContentType.JSON);
        RestAssured.baseURI = baseUri;

        RestAssured.given()
            .log().all()
            .auth().preemptive().basic("admin", "admin")
        .when()
            .get("/advertisers")
        .then()
            .log().all()
            .spec(CommonTestSpecs.requestSucceeded()); // spec that checks status == 200
    }

What is the expected output? What do you see instead?
Since I set the default responseContentType to JSON, I expect the logged 
request to contain the "Accept" header set to the "application/json" value.

Instead, I see a logged request that contains no "Accept" header. It looks like 
this:
    Request method: GET
    Request path:   https://localhost:8686/api/1.0/advertisers
    Proxy:          <none>
    Request params: <none>
    Query params:   <none>
    Form params:    <none>
    Path params:    <none>
    Multiparts:     <none>
    Headers:        Content-Type=*/*
                Authorization=Basic YWRtaW46YWRtaW4=
    Cookies:        <none>
    Body:           <none>

What version of the product are you using? On what operating system?
I am using v2.3.2, on Windows 8 (same results are obtained on a linux machine 
too)

Original issue reported on code.google.com by gabriel....@gmail.com on 25 Aug 2014 at 6:50

GoogleCodeExporter commented 9 years ago
I actually think that the accept header is set. However it's not shown in the 
request log since it has not been set explicitly by you (it's added by http 
client). See the Javadoc of the 
com.jayway.restassured.filter.log.RequestLoggingFilter. I think that it would 
be a good idea to add this header explicitly though since I think it can be 
quite confusing otherwise.

Original comment by johan.ha...@gmail.com on 28 Aug 2014 at 12:03

GoogleCodeExporter commented 9 years ago
I can confirm you are right. Looking at the httpclient logs I get in the 
console, I see stuff like:
    15:51:56.183 [main] DEBUG org.apache.http.wire - >> "GET /advertisers HTTP/1.1[\r][\n]"
    15:51:56.184 [main] DEBUG org.apache.http.wire - >> "Accept: application/json, application/javascript, text/javascript[\r][\n]"

This matches your assumption that request log does not show the Accept header, 
but that http client makes use of it.

Thanks for the info.

Original comment by gabriel....@gmail.com on 23 Oct 2014 at 7:54

GoogleCodeExporter commented 9 years ago
I'm working on this right now. I'm also about to make bigger changes for the 
accept header. Right not the accept header is automatically set based on the 
expected response specification content type which I believe is counter 
intuitive. So I'm refactoring so that the accept header must be defined 
explicitly in the request otherwise */* will be used by default. 

Original comment by johan.ha...@gmail.com on 24 Oct 2014 at 5:12

GoogleCodeExporter commented 9 years ago
using v2.4.0 with the RequestSpecBuilder makes sense to me. For instance, this 
line replaces the 3 first line of the sample test I supplied above:
  RestAssured.requestSpecification = new RequestSpecBuilder().build().baseUri(this.url).accept(ContentType.JSON).contentType(ContentType.JSON).relaxedHTTPSValidation();

Original comment by gabriel....@gmail.com on 18 Nov 2014 at 5:11

GoogleCodeExporter commented 9 years ago
Great, then I consider this fixed

Original comment by johan.ha...@gmail.com on 18 Nov 2014 at 5:18