tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [RFC] Handling the '*' URL
Date Fri, 11 Jul 2003 11:19:43 GMT
Bill Barker wrote:
> ----- Original Message -----
> From: "Remy Maucherat" <>
> To: "Tomcat Developers List" <>
> Sent: Thursday, July 10, 2003 11:29 PM
> Subject: Re: [RFC] Handling the '*' URL
>>Bill Barker wrote:
>>>This is really a Request-For-Comments, I'm not proposing anything.  I'm
>>>looking into resolving Bug #21454.
>>>At the moment, requests for e.g:
>>>  OPTIONS * HTTP/1.1
>>>  TRACE * HTTP/1.1
>>>get properly handled by TC 5 (thanks to Keith's patch), buy passing them
> to
>>>DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so
> it
>>>seems to me that it really should be handled by the Connector instead of
> the
>>>Servlet.  On the other hand, we have access to the rich Servlet-API
>>>implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So
> my
>>>problem is that I can't see the correct route to go here.
>>I'm only talking about OPTIONS here. TRACE is protocol specific for all
>>URLs (but I don't care about it ;-) ).
>>I think it should be handled by the servlet, because for example you can
>>replace the default servlet by the WebDAV servlet, and then it should
>>return the DAV methods.
> At the moment (at least in TC 5, which is the only one that returns a 200
> Response), this is handled by the Default-Servlet (which ever one is mapped
> to '/', which defaults to DefaultServlet) in the ROOT Context.  So, the
> current response according to you is still wrong if I have the the 'webdav'
> Context installed.
> <rfc-quote rfc="2616" section="9.2">
> If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
> apply to the server in general rather than to a specific resource. Since a
> server's communication options typically depend on the resource, the "*"
> request is only useful as a "ping" or "no-op" type of method; it does
> nothing beyond allowing the client to test the capabilities of the server.
> For example, this can be used to test a proxy for HTTP/1.1 compliance (or la
> ck thereof).
> </rfc-quote>
> I'm starting to lean to putting this into the Connector, rather than sending
> it to the Servlet (who can't possibly give a server-wide answer).  Note:
> I'm only interested in the case where the Request-URI.equals("*").  All
> other cases will go to the Servlet.

In my reasoning, I was implying that I had the asumption that the 
default servlet of the root context was a fair representation of what 
the server could do.

Both work for me :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message