At the moment our Android library is sensitive to response header
cases. What that means is that if a web server returns auth-token: xxxx-xxxx instead of
Auth-Token: xxxx-xxxx our RestAuthenticationModule fails to >find the token.
If the web server is returning a different token than the default token, I do not see why
it should find it. I understand it is SUPPOSED to be case insensitive, but as the blog
post and you mention, people assume it isn't. Unless the webserver is being a jerk
and randomly changing the case of the headers it is sending out, I don't think this is
a "big deal".
I'm not saying we SHOULDN'T care, just I care less about this than say, sucking in
lots of PRs and getting docs and demos out.
----- Original Message -----
From: "Marko Strukelj" <marko.strukelj(a)gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Wednesday, November 21, 2012 8:33:10 AM
Subject: [aerogear-dev] [android] Response headers case sensitivity
I found this interesting issue on the topic: https://github.com/joyent/node/issues/1954
HTTP Spec indeed says that headers are case-insensitive. But the whole world seems to go
towards a more practical approach of case sensitivity, as it’s simpler to lookup headers
Incidentally, I discovered this while using an integration testing module I’ve been
working on: https://github.com/mstruk/exploratorium-android-rest
(it's a work in
The rationale is that really testing the code means going through as much of a real
runtime as possible - like using Arquillian ...
At first I thought it was HttpClient, and HttpURLConnection APIs lowercasing the headers.
Turned out it was the embedded HTTP server.
The question in this case is do we call this an issue or is this something we don’t care
aerogear-dev mailing list