There is one other thing to point out. If you are using the Servlet APIs there are few things to point out.
- HttpServletRequest.getParameter() (and similarly named methods) - for Request URL parameters, only for POST / PUT methods, and Content-Type of `application/x-www-form-urlencoded` or `multipart/form-data` - HttpServletRequest.getInputStream() - always works (if you want to use this, then use it *before* you use any of the .getParameter() methods) - HttpServletRequest.getReader() - always works (if you want to use this, then use it *before* you use any of the .getParameter() methods) - You can only use one of .getInputStream() or .getReader(), not both at the same time, or switching between them. Joakim Erdfelt / [email protected] On Fri, Aug 16, 2019 at 10:10 AM Sonali Dasgupta < [email protected]> wrote: > Thank you so much for the explanation. Much appreciated. > > On Fri, Aug 16, 2019 at 8:17 PM Joakim Erdfelt <[email protected]> wrote: > >> Jetty has no restrictions on Request body content based on Method type >> (GET, POST, PUT, DELETE, etc). >> >> The only complication is if the request uses `Expect: 100-continue` >> See: https://tools.ietf.org/html/rfc7231#section-5.1.1 >> But even then, the request body content MUST be on the immediately >> following 100 request. >> >> The only methods with special meaning on Jetty are HEAD (which cannot >> have a Response body) >> and TRACE (which is disabled on WebApps, and causes a "405 Method Not >> Allowed") >> >> Now, that being said, having body content on GET is undefined. >> See https://tools.ietf.org/html/rfc7231#section-4.3.1 >> >> A payload within a GET request message has no defined semantics; >> sending a payload body on a GET request might cause some existing >> implementations to reject the request. >> >> >> DELETE method is in the same boat. >> See: https://tools.ietf.org/html/rfc7231#section-4.3.5 >> >> It also has the same warning. >> >> A payload within a DELETE request message has no defined semantics; >> sending a payload body on a DELETE request might cause some existing >> implementations to reject the request. >> >> >> This means that if you have a HTTP intermediary (proxy server, firewall, >> gateway, load balancer, caching server, etc) >> any of those intermediaries can also reject the GET request with body >> content. >> We see this quite often. >> >> We also see various Http Client implementations enforcing this no body on >> GET / DELETE requests. >> This is also not Jetty rejecting those requests, it's the client. >> >> Joakim Erdfelt / [email protected] >> >> >> On Fri, Aug 16, 2019 at 4:53 AM Sonali Dasgupta < >> [email protected]> wrote: >> >>> This is a question, regarding a requirement we have in our project, to >>> send a request body with a DELETE HTTP request. Various sources cite that >>> the Jetty server rejects the request body for a DELETE/GET request. Please >>> explain in depth how the jetty server handles the request body in these >>> cases ? >>> >>> >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
