On Wed, 2009-05-13 at 11:09 +0200, Paul Sandoz wrote:
> On May 12, 2009, at 6:20 PM, Paul C. Bryan wrote:
>
> > On Tue, 2009-05-12 at 18:08 +0200, Paul Sandoz wrote:
> >> On May 12, 2009, at 5:45 PM, Paul C. Bryan wrote:
> >>
> >>> Right, as it's serialized. I don't see a way to get the entity in
> >>> its
> >>> encoded form when in the handle() method.
> >>>
> >>> So, I could assume the entity is a MultivaluedMap, which I think the
> >>> majority of the time, it will be when it's POST
> >>> application/x-www-form-urlencoded. But it could be other types, up
> >>> to
> >>> the caller of the client library, correct? For example, String
> >>> (pre-encoded) seems to work if I pass that in as the entity to the
> >>> client library.
> >>>
> >>> What I'm trying to do: I want to get the entity body to extract form
> >>> parameters, in order to calculate a digital signature.
> >>>
> >>
> >>> I considered just assuming it's MultivaluedMap, and throwing
> >>> exception
> >>> otherwise, but was hoping there could be a way I could get the
> >>> encoded
> >>> entity (which I would then decode) to allow virtually any object
> >>> type to
> >>> be provided -- flexibility.
> >>>
> >>
> >> Why do you need to decode it?
> >
> > I need the name-value pairs of parameters.
>
> Why? do you need to perform some c14n of the parameter names/values?
They do need to be sorted. But also, the request is exposed to the
signature library through a Request interface, which exposes parameter
names as a set and parameter values for a given name as a list.
>
> Just curious about the signing process... and whether you can support
> signing the bytes instead, which would be a lot easier.
I could if I rework the Request interface. I'm not sure that it's worth
doing that to save myself the trouble in adapting the Jersey client. I
still believe that if it's a MultivaluedMap of POST
x-www-form-urlencoded entity, I can just use that, and only need to do
such decoding if it's a POST x-www-form-urlencoded of
non-MultivaluedMap...
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>