dev@jsr311.java.net

Re: URI Escaping and Unescaping

From: Dhanji R. Prasanna <dhanji_at_gmail.com>
Date: Fri, 22 Jun 2007 08:37:49 +1000

On 6/22/07, Bill de hOra <bill_at_dehora.net> wrote:
>
>
> Indeed. For me to add
>
> @UriTemplate("hello%20world")
>
> means I need to know the escape sequence as I type. The doing this
>
> @UriTemplate("hello world")


We're not talking about changing the URI template to auto-code. Just the URI
parameter that is extracted after the jsr311 algorithm has *already* run on
the URI and extracted the params.

will be an exception (?), as it's not legal syntax.
>
> OTOH, auto-encoding will surely confuse someone. That said, do people
> expect a programmatic API to do de/encode? I can't think of a web
> framework that does that (surely servlets don't handle escaping in
> servlet-mapping?).


Absolutely they do, at the equivalent point--a request parameter in a
servlet is available to me as "hello world" but in form method=get actually
comes in as "param=hello%20world"

Again, the framework has already *parsed* the URI, it is the
post-parse-pre-dispatch step we're talking about:

@HttpMethod(GET)
public void doGet(@URIParam("name") String name) {
   //...
}

Afaics we have already abstracted away any semblance of working with or
"like" HTTP at this point, it's all in Java now and the @URIParam annotation
is simply a high-level convenience to access the URI. It is completely
feasible for programmers who are unhappy with the high-level abstraction to
do something like:

@HttpMethod(GET)
public void doGet(HttpRequest req) {
   myDecodeLogic(req.getUri());
   //etc.
}

However, Mark's point is well taken in that I can see how this behavior is
*apparently* inconsistent and more apparently (!) so across specs. Is there
some way we can provide a utility that makes it more explicit or extend the
current one to be more lucid?

@DecodedParam(...)
ParamUtils.decode(...)

...?

Dhanji.