Re: URI Escaping and Unescaping

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 22 Jun 2007 12:43:15 +0200

Hi Mark,

I feel your JAX-WS pain :-)

I would like to highlight the following example to get a clearer
understanding of what yourself and Julian are proposing.

Given this URI template:


We would have:

  class MyResource {


Given this URI:


We could have:

  class MyResource {

       @HttpContext UriInfo uriInfo;

       public String get(
               @UriParam("up") String up,
               @QUeryParam("q%20p") String qp) {
           assert up.equals("y%20");
           assert qp.equals("z%20");
           assert uriInfo.getURIPath().equals("x%20/y%20");

           return URI.create(uriInfo.getURIPath() + "?q%20p=" + qp).

And when we do GET to the URI http://localhost/x%20/y%20?qp=z%20 no
assertions will fail and the following entity will be returned:


Is that what you are proposing?

1) that URI templates and query parameter names must always be
    declared in encoded form;

2) the URI path, template values and query parameter values, when
    accessed as strings, must be returned in encoded form; and

3) the developer must explicitly decode those of 2).


Mark Hansen wrote:
> Actually, I *strongly* disagree with the emerging consensus (Dhanji,
> Phil, David) on this.
> I don't think that JSR-311 should make any effort to abstract
> away the URL encoding from the developer. Automating the
> encoding/decoding will just be (1) a source of confusion for
> developers and (2) a source of bugs for implementers.
> Regarding (1) - URL encoding is a fact of life for RESTful
> development. Lets not try to hide the realities of the Internet from
> programmers. Heading down that path just starts to get confusing. Then,
> to use our API, programmers have to remember what algorithm we
> use to map Strings to URL encoded Strings. Or worse, developers who
> don't know about URL encoding will wonder why their code does one
> thing, but when you copy and paste that query string into a Browser, it
> doesn't work.
> Our goal should be to make Java work the way that the Internet
> works. My biggest frustration with JAX-WS (and this is also a problem
> with is that it tries too hard to abstract the
> programmer away from the Internet. Our goal on JSR-311 should be to
> provide a natural Java representation of what is really going on on the
> Internet. Hiding the messy stuff in the name of "easier programming"
> is a bad idea.
> Regarding (2) - If we start coming up with rules for how to make URL
> encoding "easier", I guarantee you that it will be source of bugs in
> the implemenation. Here is an example from JAX-WS:
> Today, I have spend several hours trying to find some bug in how the
> JAX-WS 2.1 RI implemenation handles URL encoding/decoding.
> Its a query of the Yahoo Shopping API. Works fine in a browser. But,
> when I use the encoded query string with a Dispatch<T>, by
> setting the MessageContext.QUERY_STRING, it doesn't work (at least not
> in build 42 - I'm trying a newer build before filing a bug report)..
> Like this:
> productSearchDispatch.getRequestContext().put(MessageContext.QUERY_STRING,
> "appid=soajavabook&query=razr&category=Electronics%20%26%20Camera");
> It used to work in one of the older JAX-WS builds. Now it doesn't. Bugs
> like this appear, get fixed, disappear, and come back again.
> -- Mark

| ? + ? = To question
    Paul Sandoz