hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nels N. Nelson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-104) Handler Registry Should Match Using Regular Expressions
Date Mon, 23 Jul 2007 21:03:31 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514778
] 

Nels N. Nelson commented on HTTPCORE-104:
-----------------------------------------

Hello Oleg, Roland, 
    Thanks for your time with this issue.

    I too would indeed like to be able to make my app be portable to the Java ME platform.
 I know of at least one "competing" application in particular that is compatible with 1.3,
which is why I planned to make my project also be portable to 1.3.  I was not going to refactor
my project to work with 1.3 until much later, but since the changes I suggested will *never*
be implemented, and for good reasons, it seems prudent to refactor my project right away.

    I am currently researching query string handling techniques that meet this portability
requirement, but I would prefer to use any code that already exists in, or is based on, or
is related to, the httpcore project.  Do you happen to know of anything like that already?
-Nels

> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
>                 Key: HTTPCORE-104
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-104
>             Project: HttpComponents Core
>          Issue Type: Improvement
>          Components: HttpCore
>    Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
>            Reporter: Nels N. Nelson
>             Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern,
final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
>     protected boolean matchUriRequestPattern(final String pattern, 
>         final URI requestUri) 
>     {
>         try {
>             String path = requestUri.getPath();
>             Pattern p = Pattern.compile(pattern);
>             Matcher matcher = p.matcher(path);
>             return matcher.matches();
>         }
>         catch (java.util.regex.PatternSyntaxException ex) {
>             return false;
>         }
>     }
> </code>
> These changes would make this code far more accurate:
> <code>
>     protected void doService(
>             final HttpRequest request, 
>             final HttpResponse response,
>             final HttpContext context) throws HttpException, IOException {
>         HttpRequestHandler handler = null;
>         if (this.handlerResolver != null) {
>             URI requestURI = request.getRequestLine().getUri();
>             handler = this.handlerResolver.lookup(requestURI);
>         }
>         if (handler != null) {
>             handler.handle(request, response, context);
>         } else {
>             response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
>         }
>     }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code>
to represent the <code>requestURI</code> parameter throughout the code.  This
has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code>
class, for instance), and flexibility of extension.  I can enumerate the specifics on this,
if necessary, but I believe that would be a discussion for a separate Jira Issue, which I
will happily create, if I am convinced that its priority would be at least major, which currently,
I am not.  Such a change would cause several changes throughout multiple classes, stemming
from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
>     String getMethod();
>     HttpVersion getHttpVersion();
>     URI getUri();
>     
> }
> </code>
> Thanks for your attention to this issue.
> -Nels

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message