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]<mailto:[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?
