Hi

Yes, it looks like a good idea. I'm also going to commit a JSONP patch
shortly, and you will be able to extend the inbound interceptor and update
the Message headers as needed.

Message.QUERY_STRING key references the query itself, "HTTP_REQUEST" -
HttpServletRequest (you can check parameters or queries),
Message.PROTOCOL_HEADERS - the map of headers

Thanks, Sergey

On Fri, Apr 8, 2011 at 4:16 PM, KARR, DAVID (ATTSI) <[email protected]> wrote:

>  Just so it’s clear, I’m talking about the fact that the “Accept” header,
> or any other HTTP header, cannot be sent from a “script” block. The only
> choice we would have would be to send query/request parameters.  I’m trying
> to figure out the cleanest way to enable use of query parameters for
> functions usually specified by headers, without changing my controller,
> which specifies the use of HTTP headers.
>
>
>
> My current thought is to have an interceptor check for specific query
> parameters, perhaps in a configurable map, and translate those to HTTP
> headers, and hopefully this can be done before CXF makes decisions based on
> the presence of particular HTTP headers.
>
>
>
> *From:* Sergey Beryozkin [mailto:[email protected]]
> *Sent:* Friday, April 08, 2011 3:44 AM
> *To:* KARR, DAVID (ATTSI)
> *Cc:* [email protected]
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> Hi David
>
> I think I have to apply the JSONP patch that we have asap :-), and catch up
> a bit with the way JSONP works.
> I'm still not sure I follow, basically, looks like you'd like to have some
> utility code available that can say take the value of Accept header and
> return a sorted list, yes ? If no then please post an example with some
> pseudo code showing what are the actual expectations
>
> Cheers, Sergey
>
>  On Thu, Apr 7, 2011 at 11:27 PM, KARR, DAVID (ATTSI) <[email protected]>
> wrote:
>
> Perhaps I wasn’t clear.  The app currently checks for certain header
> parameters, along with some query parameters.  In order to be fully usable
> from JSONP script tags, I’ll have to get it to work by using query
> parameters for what I’m currently using header parameters for.  As to a
> format of the query parameters, that doesn’t particularly matter.  If it’s
> more workable to have a bunch of former header parameters embedded into a
> single query parameter somehow, I suppose that could work, if there was some
> reason that was more convenient than individual query parameters.
>
>
>
> *From:* Sergey Beryozkin [mailto:[email protected]]
> *Sent:* Thursday, April 07, 2011 2:57 PM
> *To:* [email protected]
> *Cc:* KARR, DAVID (ATTSI)
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> Hi
>
> Can you explain a bit more how it works. Do you have individual query
> parameters representing individual HTTP headers in this case ? Can you post
> a simple example ?
>
> Cheers, Sergey
>
> On Thu, Apr 7, 2011 at 10:45 PM, KARR, DAVID (ATTSI) <[email protected]>
> wrote:
>
> My CXF JAX-RS app currently looks at a couple of "standard" HTTP headers,
> being "Accept" and "Accept-Language".  It also uses a custom HTTP header.
>
> It's come to my attention that we need to examine whether we can support
> being called from a "script" tag, to support JSONP callbacks.  This will not
> allow changing HTTP headers.  I can easily enough change my code to check
> for my custom header as a query parameter instead of an HTTP header, but the
> situation isn't as simple for "Accept" and "Accept-Language", which are
> processed implicitly by CXF.
>
> Presently handling of "Accept" is done without any effort on my part,
> except for perhaps the "@Produces" annotation.  Handling of
> "Accept-Language" is done with almost as little effort, requiring me to call
> the "HttpHeaders.getAcceptableLanguages()" function.
>
> What are some reasonable strategies for getting this information (and using
> it, more importantly) from request parameters instead?
>
>
>
>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com

Reply via email to