Hi Hermann
if we rely on the runtime (ex, HttpUrlConnection) setting some of those
headers then no, they can not be read.
If the client filters have an idea of what Host, User-Agent, etc has to
be set to then they can indeed set them and get those values signed too.
Sergey
On 14/01/15 09:46, Hermann Angstl wrote:
Hello,
sorry for the late follow-up ;-)
Re:
Most of these headers can be set from the filter itself, or from HttpConduit,
...
Setting headers is not my problem. I want to READ them.
When I try to access the headers in filters, interceptors, etc. all I get in the PROTOCOL_HEADERS
is "Content-Type" and "Accept".
Is there a way to have READ access to headers like "Host", "Date",
"User-Agent", etc. ?
I'd like to read those, do some checksum/signature voodoo magic with them - and
then store it as a new header in the message.
cheers,
Hermann
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Montag, 22. Dezember 2014 13:23
To: [email protected]
Subject: Re: Signing HTTP Requests in JAX-RS
Hi Hermann
On 22/12/14 11:35, Hermann Angstl wrote:
I'd like to sign HTTP Requests (similar to this
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00).
Therefore I need access to HTTP-Header fields like "Content-Length", "Host", "Date",
"User-Agent", etc.
I tried using ClientRequestFilter, WriterInterceptor and
AbstractPhaseInterceptor (with a very late phase (Phase.SEND)) to implement
this functionality - but it seems the HTTP Headers are set very late - and are
out of my reach.
All I get in the PROTOCOL_HEADERS is "Content-Type" and "Accept".
Does CXF provide a functionality to have access to this kind of information (in
an interceptor)?
Wheather or not my use case makes sense - imho it generally would be
nice to have this functionality ;-)
Most of these headers can be set from the filter itself, or from HttpConduit,
for example, I've checked an HttpClientPolicy class, and it supports setting
headers like Host, Connection, etc... User-Agent can be set from a filter if
preferred.
Content-Length can be set too if an entity is byte[] or if the entity out
stream is cached - in the latter case you'd check the cached content length,
set Content-Length, and only then write the cached entity bytes out. You may
still need to disable the chunked encoding though to ensure the low-level
transport mechanism does not interfere if the chunked encoding is enabled...
So basically pretty much any HTTP Header can be set from the code - however in
some cases in can be problematic, for example, if you send a 1MB PDF then
caching it in order to get Content-Length in advance won;t be effective; may be
not an issue if the payloads are generally small...
FYI I've also asked for the clarifications be added to the draft re which
headers can be dropped during the signing process
Thanks, Sergey
cheers,
Hermann
