You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2007/07/20 20:34:06 UTC

[jira] Closed: (HTTPCORE-104) Handler Registry Should Match Using Regular Expressions

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

Roland Weber closed HTTPCORE-104.
---------------------------------

    Resolution: Won't Fix

Hello Nels,

your suggestions share one fault:
- regular expressions are Java 1.4
- class URI is Java 1.4
whereas
- core module-main is Java 1.3

HttpRequestHandlerRegistry is really just the default implementation of interface HttpRequestHandlerResolver, you are of course welcome to have a different implementation of that interface, using newer Java versions. If you feel like contributing it, we'd be happy to include it in our contrib code.
A request implementation class that keeps an instance of URI is available in HttpClient as of alpha1, which has just been released. Unlike core module-main, HttpClient requires Java 1.4 and can therefore use the URI class.
http://jakarta.apache.org/httpcomponents/httpcomponents-client/httpclient/apidocs/org/apache/http/client/methods/HttpUriRequest.html

cheers,
  Roland


> 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, 4.0-beta1, 4.0-rc1
>
>
> 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