New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

charset=UTF-8 appending to Content-Type for client defined in xml #246

Closed
mikeloll opened this Issue May 25, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@mikeloll

mikeloll commented May 25, 2017

I may have found a bug..

When configuring an http-client using the XML syntax, if you set the content-type attribute and then use the client in a Java dsl call, it will append charset=UTF-8 to the content type.

If you call contentType() on the http builder and give it your content type (with no charset parameter) it will not append the charset.

I would expect that what is configured in the xml would be honored and not modified.

@mikeloll

This comment has been minimized.

mikeloll commented May 25, 2017

@christophd

This comment has been minimized.

Member

christophd commented May 28, 2017

I am confused here. I would expect the test case DSL send operation to always overwrite the XML component configuration. So if you set a content type in the send operation via Java DSL the constructed message should have this content type setting. If you not set the content type in Java DSL the default content type specified in XML should be applied.

@mikeloll

This comment has been minimized.

mikeloll commented May 30, 2017

That is what I would expect, but that is not what I am seeing.

@christophd christophd added READY and removed State: To discuss labels Jun 13, 2017

@christophd christophd added this to the v2.7.2 milestone Jun 13, 2017

@christophd christophd added IN PROGRESS and removed READY labels Jun 30, 2017

@christophd christophd self-assigned this Jun 30, 2017

@christophd

This comment has been minimized.

Member

christophd commented Jul 4, 2017

I have the following client endpoint defined:

<citrus-http:client id="httpClient"
             request-url="http://localhost:8080/test"
             request-method="POST"
             content-type="text/xml"/>

Content-Type is set to "text/xml". I use this client in Java DSL:

http(action -> action.client("httpClient")
            .send()
            .get());

I get following request:

HTTP/1.1 GET /test
Host:localhost:8080
Accept:text/plain, application/json, application/*+json, */*
Content-Type:text/xml;charset=UTF-8

Notice: The charset=UTF-8 is automatically added with underlying Http client implementation.
When I overwrite the Content-Type in Java DSL:

http(action -> action.client("httpClient")
            .send()
            .get()
            .contentType("text/xml"));

I get following request:

HTTP/1.1 GET /test
Host:localhost:8072
Accept:text/plain, application/json, application/*+json, */*
Content-Type:text/xml

Notice: Content-Type has been added as-is defined in Java DSL. So Java DSL overwrites XML endpoint configuration. This is a total expected behavior to me. Someone could argue that the charset is added automatically but this would be another question.

About to close this issue - any objections?

@christophd christophd modified the milestones: SOMEDAY, v2.7.2 Jul 4, 2017

@christophd

This comment has been minimized.

Member

christophd commented Jul 4, 2017

Sorry I have to correct some of my previous statements. The charset is not added with underlying Http client implementation but within Citrus Http message converter. This is because the charset is a separate attribute on the http client component and defaults to "UTF-8".

So I have added the opportunity to set the charset to empty string in http client configuration:

<citrus-http:client id="httpClient"
         request-url="http://localhost:8080/test"
         request-method="POST"
         charset=""
         content-type="text/xml"/>

After that the charset is not automatically added to the Content-Type header as you expected in the first place. Sorry again!

@christophd christophd modified the milestones: v2.7.2, SOMEDAY Jul 4, 2017

@christophd christophd closed this in 8bea2d6 Jul 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment