Hi,
that might be tricky, not from Grizzly perspective but in general, cause
if you send response and immediately close connection at the time when
client still sends a request body, most probably client will hit
IOException and not be able to read server's response. That's why if you
want to make sure client receives status (response) from server, you
have to read entire request on the server side.
Or, if you have control over client code, you can use HTTP 100-Continue
(which is also supported by Grizzly [1]), in this case client have to
send HTTP headers (along with additional "Expect: 100-Continue" header)
and depending on server response (accept or refuse) client will send the
content or not.
Hope it will help.
WBR,
Alexey.
[1]
http://java.net/projects/grizzly/sources/git/content/modules/http-server/src/test/java/org/glassfish/grizzly/http/server/HttpContinueTest.java
On 07/10/2012 01:20 PM, gOA-pSY wrote:
> Hello,
>
> I have an instance of a org.glassfish.grizzly.http.server.HttpServer and
> I added an org.glassfish.grizzly.http.server.HttpHandler instance.
>
> Now I have to implement the
>
> public void service(final Request request, final Response response)
> throws Exception {}
>
> method.
>
> Now I need to look at the request and if certain conditions match, I
> want to "cancel" the request and immediately reply with different status
> codes. Currently the client has to complete the request (some MB of
> data) but I don't want to waste bandwith on both sides.
>
> If I call request.getRequest().getConnection().close() nothing is sent
> to the client but at least the upload is canceled.
>
> Does anyone have a hint how to solve this issue?
>
> Greetings