Closed GoogleCodeExporter closed 9 years ago
I completed this for the Authorization header here:
https://codereview.appspot.com/6736062/
Need to make the same change for all other headers.
Original comment by yan...@google.com
on 22 Oct 2012 at 7:31
Original comment by yan...@google.com
on 22 Oct 2012 at 7:32
We'll also need to do this for all subclasses of HttpHeaders in the sister
projects, such as GoogleHeaders and SubscriptionHeaders
Also, we should change the setter methods to accept any Object -- not just
String -- and return this (and be overridden in the subclass to change return
type).
The getter method is the more problematic one. We could keep the current
signature and just cast to String and let a ClassCastException be thrown.
Users may rightly complain that this is a bug because multiple headers are a
legitimate use case. This is the only backwards-compatible option, but
thankfully we're still in Beta so it is not strictly required.
Another object is to not cast and change the return type to Object. Although
theoretically more correct, it is also more annoying because you have to cast
the result and have them worry about it potentially having a value of any kind,
whereas typically it will only be String or List<String>.
Another alternative is to try to do something "clever" like returning
Iterable<String> which if instanceof String would return
Collections.singleton() of the value. We could even write a static utility
method to simplify this, so the implementation would be for example "return
asIterableString(authorization);".
Opinions?
Original comment by yan...@google.com
on 24 Oct 2012 at 1:44
The paragraph above should instead be:
Another option is to not cast and instead change the return type to Object.
Although theoretically more correct, it is also more annoying because
developers will have to cast the result and worry about return value
potentially being of any type, whereas typically it will only be String or
Iterable<String>.
Original comment by yan...@google.com
on 24 Oct 2012 at 1:46
Another question is whether we want to have a single "setAuthorization(Object)"
or two methods "setAuthorization(String)" and
"setAuthorization(Iterable<String>)" (either Iterable or Collection). We could
even add "setAuthorization(String, String...)" instead of
"setAuthorization(String)". I don't have a strong feeling about it at this
point.
Original comment by yan...@google.com
on 24 Oct 2012 at 7:52
Original comment by yan...@google.com
on 14 Nov 2012 at 7:24
Original comment by yan...@google.com
on 15 Nov 2012 at 9:27
https://codereview.appspot.com/6846062/
Original comment by yan...@google.com
on 16 Nov 2012 at 1:36
Original comment by yan...@google.com
on 28 Nov 2012 at 5:11
Concerned that changing all header fields to be a list is going to break
parsing of date. The http header date specification doesn't say it allows
brackets:
See section 14.18:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
Original comment by daniel...@google.com
on 20 Dec 2012 at 2:36
Daniel, as we discussed the problem is that any code that calls get(String) and
then toString() is now going to get a bracket because internally we represent
the header value as a List<String> instead of String (to match the HTTP
specification).
The fix is to call getFirstHeaderStringValue(String) instead. That way you
don't rely on the internal implementation details of HttpHeaders.
Thanks for the feedback though. I'm sure a lot of developers are going to run
into a similar problem.
Original comment by yan...@google.com
on 20 Dec 2012 at 1:05
Original issue reported on code.google.com by
yan...@google.com
on 20 Oct 2012 at 1:29