Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] CONNECT and getRequestURI ?

It could be either. Making it configurable would be more effort than its worth.

I have no strong preference for either.

Mark


On 21/02/2023 17:11, Ph. Dinh wrote:
Can it be either 405 or 501?
------------------------------------------------------------------------
*From:* servlet-dev <servlet-dev-bounces@xxxxxxxxxxx> on behalf of Mark Thomas <markt@xxxxxxxxxx>
*Sent:* Tuesday, February 21, 2023 7:24 AM
*To:* servlet-dev@xxxxxxxxxxx <servlet-dev@xxxxxxxxxxx>
*Subject:* Re: [servlet-dev] CONNECT and getRequestURI ?
On 14/02/2023 23:51, Greg Wilkins wrote:

All,

I'm not advocating that we support CONNECT.  Just asking what should the standard behavior be if we do get a CONNECT request.

Ack.

Note that the spec saying that CONNECT is not supported is not very strong. It is in the context of the API of the Servlet and not so much a requirement of the server.

Fair enough.

I'd be happy with a requirement that a CONNECT request be handled with a 405 response.... and then the return from getRequestURI does not matter.

Any objections to a PR to that effect?

Mark



cheers




On Tue, 14 Feb 2023 at 22:12, Masao Sato <masato@xxxxxxxxxx <mailto:masato@xxxxxxxxxx <mailto:masato@xxxxxxxxxx>>> wrote:

      >I'll note that the Spec document explicitly states that the CONNECT
      >method is not supported.

     Because of that the CONNECT request could not be treated as a normal
     http request,
     HttpServlet and HttpServletRequest  are not filt to handle it.
     The spec has a Servlet and ServletReqeust ( not HttpServletRequest )
     interfaces
     for generic protocols, all extended methods from ServletRequest except
     getMethod()
     should throw some exception. and the application should forward to  a
     servlet which
     inherited Servlet ( not HttpServlet ) by calling
     ServletRequest#getRequestDispatcher().

     Regards,
     Masao Sato

     2023年2月14日(火) 18:32 Mark Thomas <markt@xxxxxxxxxx
     <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>>:
      >
      > On 14/02/2023 00:15, Stuart Douglas wrote:
      > > If you don't like null because of the potential for NPEs I
     think you
      > > could also make a similar argument for the empty string. If
     developers
      > > are not thinking about connect requests they could assume that
     it will
      > > always be at least length 1 and you could end up with different
     exceptions.
      > >
      > > Stuart
      > >
      > > On Tue, 14 Feb 2023 at 11:07, Greg Wilkins <gregw@xxxxxxxxxxx
     <mailto:gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>>
      > > <mailto:gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx
<mailto:gregw@xxxxxxxxxxx>>>> wrote:
      > >
      > >
      > >     So options are now null, "" and "/".  Older jetty was "", newer
      > >     jetty is null and undertow is "/".
      > >     Where does tomcat land in this?   I'm very happy to change
     jetty to
      > >     anything, I just want it to be standard.
      > >     I think null is probably my least favourite and I'm on
     fence with ""
      > >     vs "/".
      >
      > Tomcat currently returns a 400 response.
      >
      > I'll note that the Spec document explicitly states that the CONNECT
      > method is not supported.
      >
      > Unless we think there are web applications that actually want to
      > implement CONNECT, I'm leaning towards requiring a 405 response
     to all
      > CONNECT requests.
      >
      > I found one request to implement CONNECT on the Tomcat users list
     from
      > 2016 and I'm not convinced that was the correct solution to the
     problem
      > the user was facing.
      >
      > If we do change the spec to permit CONNECT requests, then I think
     we'll
      > need to:
      > - add a doConnect() method to HttpServlet
      > - specify the expected value for getRequestURI()
      > - specify how the CONNECT request is mapped to a Servlet
      >
      > Mark
      > _______________________________________________
      > servlet-dev mailing list
      > servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>>
      > To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
<https://www.eclipse.org/mailman/listinfo/servlet-dev>
     <https://www.eclipse.org/mailman/listinfo/servlet-dev
<https://www.eclipse.org/mailman/listinfo/servlet-dev>>



     --      レッドハット株式会社
     サービス事業統括本部
     佐藤 将夫

     _______________________________________________
     servlet-dev mailing list
     servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>>
     To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
<https://www.eclipse.org/mailman/listinfo/servlet-dev>
     <https://www.eclipse.org/mailman/listinfo/servlet-dev
<https://www.eclipse.org/mailman/listinfo/servlet-dev>>



--
Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>>> CTO
http://webtide.com <http://webtide.com> <http://webtide.com
<http://webtide.com>>

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
<https://www.eclipse.org/mailman/listinfo/servlet-dev>
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev <https://www.eclipse.org/mailman/listinfo/servlet-dev>

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev


Back to the top