[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    [jira] Commented: (HTTPCORE-104) Handler Registry Should Match
From:       "Oleg Kalnichevski (JIRA)" <jira () apache ! org>
Date:       2007-07-23 21:24:31
Message-ID: 17404926.1185225871295.JavaMail.jira () brutus
[Download RAW message or body]


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

Oleg Kalnichevski commented on HTTPCORE-104:
--------------------------------------------

Hello Nels, 

You may want to take a look at Commons Codec [1]. It will not give you a complete \
solution, as you would still have to parse request query into an array of name/value \
pairs by yourself, but at least you could make use of URLCodec to decode values. 

Oleg

[1] http://jakarta.apache.org/commons/codec/

> 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


[prev in list] [next in list] [prev in thread] [next in thread]