Re: [jetty-users] Can Jetty decide not to respond to a request?

[Greg Wilkins <gregw@xxxxxxxxxxx>]

and just to add some more options... 

if you are using Jetty APIs then calling abort(Throwble) on the HttpChannel is he best transport independent way to do a GO_AWAY style semantic.    Doing a sendError(-1) will also trigger an abort under the scenes (and can be done from a servlet).

Finally, throwing BadMessageException is another way to handle this.  It will send a 400 and then close the connection.

cheers

On Mon, 16 Mar 2020 at 19:27, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

Hi,

On Mon, Mar 16, 2020 at 5:13 PM Glen Peterson <glen.k.peterson@xxxxxxxxx> wrote:
>
> My first choice would be to decide not to respond from within an AbstractHandler's handle() method, after examining the (HttpServlet)Request.  But if there's another place we can examine the request (ideally in Java), that would work too.  Right now I've got some code like:
>
> object MyHandler: AbstractHandler() {
>
>     override fun handle(target: String,
>                         baseRequest: Request,
>                         request: HttpServletRequest,
>                         response: HttpServletResponse) {
>
>         val rawPath = request.getPathInfo()
>
>         // We don't have any PHP files.  Any attempt to access one is hacking.
>         if ( rawPath.endsWith(".php") ) {
>             logger.info("BOGUS Request: [${request.pathInfo}]")

baseRequest.getHttpChannel().getEndPoint().close();

However, in general is not that big of a difference to send a 400
(response.sendError(400)), it's more standard and will work for the
years in future.

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

--

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