hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HTTPCORE-104) Handler Registry Should Match Using Regular Expressions
Date Fri, 20 Jul 2007 18:34:06 GMT

     [ 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


Mime
View raw message