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

["Nels N. Nelson (JIRA)" <ji...@apache.org>]

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

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

Roland,
    Thanks for your response.  I see your points, and I agree with you.  This has caused me to realign 

    May I ask, can you recommend any 1.3-compatible code for handling the query strings of plain old string literal uris?  I do not see any existing code for such functionality in the httpcore codebase.  I'm guessing I'll have to write my own, or co-opt some open source library, but I'd like to see if I can keep my current project as close to the requirements of the httpcore project requirements as possible.
-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