Closed GoogleCodeExporter closed 9 years ago
That's probably because that HTTP Builder doesn't care about it. In the next
version I've forked HTTP Builder so now I can control most things. Not sure if
this will make it to the next release though. Thanks for reporting.
Original comment by johan.ha...@gmail.com
on 2 Feb 2012 at 7:16
Original comment by johan.ha...@gmail.com
on 3 Feb 2012 at 9:46
Any update or workaround for this issue?
Original comment by thomas.l...@gmail.com
on 26 Jun 2013 at 3:42
No not yet :(
Original comment by johan.ha...@gmail.com
on 27 Jun 2013 at 5:38
In RequestSpecificationImpl.grooy, RestAssuredHttpBuilder.doRequest(): headers
are added but not overriden. The problem is that the "Accept-Encoding" header
has already been set in the constructor of the ancestor class HTTPBuilder:
this.setContentEncoding(ContentEncoding.Type.GZIP,ContentEncoding.Type.DEFLATE)
Maybe a quick & dirty fix would be to delete this line (why would the HTTP
client enable compression if not asked by the API user anyway ?).
Original comment by thomas.l...@gmail.com
on 28 Jun 2013 at 12:07
The problem with the quick fix is that it breaks backward compatibility without
a good way to add GZIP support. I think we need to solve it in a better way.
Original comment by johan.ha...@gmail.com
on 1 Jul 2013 at 10:46
That's why I called it dirty :-)
Another simple way would be to allow overriding headers. Is there a reason to
only allow adding headers but not override already existing ones ?
Original comment by thomas.l...@gmail.com
on 1 Jul 2013 at 11:59
The only reason is that Rest Assured forked HTTP Builder which had this as
default behavior. I've simply not have time to fix it properly :)
Original comment by johan.ha...@gmail.com
on 1 Jul 2013 at 12:19
I propose a pull request that keeps the default behavior. Tell me what you
think about it: https://github.com/jayway/rest-assured/pull/17
Original comment by thomas.l...@gmail.com
on 2 Jul 2013 at 1:18
Good work! However I would prefer to have it in a configuration, called
something like ContentEncodingConfig or AcceptEncodingConfig. This way it's
possible to define it statically for all requests (using RestAssured.config =
..) or using it an a request specification builder for better re-use. See for
example com.jayway.restassured.conf ig.ObjectMapperConfig. It might be a good
idea to a have a shortcut to setting the content encoders like you've done with
the "acceptEncoding" method in the RequestSpecification as well.
Btw, do you think it ought to be called "acceptEncoding" or
"contentEncoding"/"contentEncoders"? Perhaps setting the Accept-Encoding header
is just a side-effect of specifying a content encoder?
So would you be so kind to make it a config instead and amend that to the pull
request? I think you've done a great start but making it a config would, in my
view, be a more correct way to do it for the reasons mentioned earlier.
Original comment by johan.ha...@gmail.com
on 3 Jul 2013 at 5:26
I tried to follow your advices in my new commit.
Original comment by thomas.l...@gmail.com
on 3 Jul 2013 at 2:36
Thanks! I'll try to take a look at it during the day or this evening.
Original comment by johan.ha...@gmail.com
on 4 Jul 2013 at 5:56
You can now configure this in the DecoderConfig
Original comment by johan.ha...@gmail.com
on 14 Nov 2013 at 9:12
Original issue reported on code.google.com by
rus...@gmail.com
on 2 Feb 2012 at 1:21