cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Handling "Accept" and "Accept-Language" in query parameters
Date Thu, 14 Apr 2011 09:03:56 GMT
Hi


On Wed, Apr 13, 2011 at 11:08 PM, KARR, DAVID (ATTSI) <dk068x@att.com>wrote:

>  Hmm, so you believe the spec indicates that “.xml.en” would not work?  I
> appear to be unable to download the spec at this moment (times out), so I
> can’t search for it.  If you happen to find a statement in the spec that
> indicates this, I would appreciate it.  Otherwise, I’ll try downloading the
> spec at another time and see if I can find it.
>
>
I've checked this version of the spec:
http://jsr311.java.net/drafts/spec20080627.pdf

it is the 3rd from the top of the list shown here:
http://jsr311.java.net/history.html

and actually it does allow for ".xml.en" too :-). But the whole idea was
dropped in the next version, not really sure why.
Sure, it can conflict with the real resource URIs but the docs for given
service can provide info on whether this sort of request URI preprocessing
is supported or not. Anyway CXF still supports it, Jersey should too. We
just don't support "en.xml" & "xml.en", only 'en.xml', as well as '.en' and
'.xml' forms

Cheers, Sergey



>
>
> *From:* Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> *Sent:* Wednesday, April 13, 2011 2:45 PM
>
> *To:* KARR, DAVID (ATTSI)
> *Cc:* users@cxf.apache.org
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> Hi
>
> On Wed, Apr 13, 2011 at 8:40 PM, KARR, DAVID (ATTSI) <dk068x@att.com>
> wrote:
>
> Considering the question of “.xml.en” vs. “.en.xml”, I’m working with
> someone who actually claims that it should ONLY work for the latter, and
> that the former is “not well-formed” (my wording).  I don’t buy his
> argument, but what do you think?
>
>
> I can see in the code that indeed it is only the combination like
> “.en.xml” that will work, and it must've been the earlier spec requirement
> that dictated it.
>
> I'm not quite sure why a combination like 'xml.en' would not work in
> principle, "resource.en.xml" or "resource.en"or "resource.xml" won't work
> too if a given service happens to expose a resource with the final path
> segment matching say "resource.xml". There could be some subtleties there,
> just not aware of them
>
> Cheers, Sergey
>
>
>
> *From:* Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> *Sent:* Tuesday, April 12, 2011 12:53 PM
> *To:* KARR, DAVID (ATTSI)
> *Cc:* users@cxf.apache.org
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> No, JsonpInInterceptor, with two out interceptors are utility interceptors
> that have been added to the trunk as part of the patch.
> Re your other questions, you can do
>
> /resource.xml.en
>
> and that will override both Accept and Accept-Language, provided mappings
> are available.
>
> I don't recall now, it was probably part of JAX-RS 0.8, for some reasons it
> did not make it into the final spec, not sure why
>
> Cheers, Sergey
>
> On Tue, Apr 12, 2011 at 5:25 PM, KARR, DAVID (ATTSI) <dk068x@att.com>
> wrote:
>
> Concerning the “JsonpInInterceptor”, is this the class that you have a
> pending patch for?  Assuming that’s true, what is the issue that’s addressed
> by the patch?
>
>
>
> *From:* Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> *Sent:* Tuesday, April 12, 2011 8:24 AM
>
>
> *To:* KARR, DAVID (ATTSI)
> *Cc:* users@cxf.apache.org
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> Hi
>
> Perhaps JsonpInInterceptor [1] can be extended ? If you think it will help
> then may be you can submit a small patch ?
>
> But see also [2], you can use extension and language mappings to override
> Accept and Accept-Language
>
> Cheers, Sergey
>
>
> [1]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/jsonp/JsonpInInterceptor.java
> [2]
> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-Debugging
>
> On Tue, Apr 12, 2011 at 4:54 AM, KARR, DAVID (ATTSI) <dk068x@att.com>
> wrote:
>
> It was straightforward for me to write an additional interceptor to
> translate specific query params to headers (A list property defined in
> Spring specifies the list of parameter names to check for).  Is this
> basically what you meant by that?  Seems like this is something that should
> be a reusable component.
>
>
>
> *From:* Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> *Sent:* Friday, April 08, 2011 10:20 AM
> *To:* KARR, DAVID (ATTSI)
> *Cc:* users@cxf.apache.org
> *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters
>
>
>
> 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) <dk068x@att.com>
> 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:sberyozkin@gmail.com]
>
> *Sent:* Friday, April 08, 2011 3:44 AM
> *To:* KARR, DAVID (ATTSI)
> *Cc:* users@cxf.apache.org
>
> *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) <dk068x@att.com>
> 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:sberyozkin@gmail.com]
> *Sent:* Thursday, April 07, 2011 2:57 PM
> *To:* users@cxf.apache.org
> *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) <dk068x@att.com>
> 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
>
>
>
>
>
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend <http://www.talend.com>
> http://sberyozkin.blogspot.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message