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 18:27:31 GMT

    [ 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:

    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.

> 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

View raw message