<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Dridi,<div class="">Thanks for the response. I’m curious what specifically you believe to be in violation of the spec here. There’s a lot of ambiguity to be had by my read, but the option to send responses at any point seems pretty clear. From RFC 7230 Section 6.5 </div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; break-before: page;"> A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of
the connection.</pre><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">I should point out I initiated a thread on the Jetty mailing list on this same topic prior to this one, and they (perhaps unsurprisingly) defend this behavior. Greg Wilkins of the Jetty team asked me to relay this message in particular: <a href="https://www.eclipse.org/lists/jetty-users/msg08611.html" class="">https://www.eclipse.org/lists/jetty-users/msg08611.html</a> </div><div class="">As I mentioned in that thread, I have no horse in this race and just want to solve my problem and perhaps spare others from this same issue, which was rather tough to debug.</div><div class=""><br class=""></div><div class="">Tommy</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 27, 2018, at 9:40 AM, Dridi Boukelmoune <<a href="mailto:dridi@varni.sh" class="">dridi@varni.sh</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class="">On Wed, Sep 26, 2018 at 2:44 AM Tommy Becker <<a href="mailto:twbecker@gmail.com" class="">twbecker@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">We have an application that we front with Varnish 4.0.5. Recently, after an application upgrade in which we migrated from Jetty 9.2 to 9.4, we began noticing a lot of 503s being returned from Varnish on POST requests. We have an endpoint that takes a payload of a potentially large amount of JSON, and validates it as it’s being read. What we have discovered is that if there is a problem with the content, we correctly return a 400 Bad Request from Jetty. Notably, this can happen before the entire content is received. When this happens, Varnish continues to send the remainder of data, despite having already seen the response. Now after our upgrade, Jetty's behavior is to send a TCP RST when this happens (since the data is unwanted by the application). Unfortunately, Varnish interprets the RST as a backend error, and goes to vcl_backend_error, having never sent the original response returned from Jetty to the client. So instead of seeing a 400 Bad Request with a helpful message, they simply get 503 Service Unavailable.<br class=""></blockquote><br class="">I'm pretty certain that this optimization does not comply with the<br class="">HTTP/1 specs. Even though Jetty is trying to improve the latency by<br class="">replying early, as far as Varnish is concerned it failed to send the<br class="">full request and won't bother reading the response.<br class=""><br class=""><blockquote type="cite" class="">I found this issue which seems similar: <a href="https://github.com/varnishcache/varnish-cache/issues/2332" class="">https://github.com/varnishcache/varnish-cache/issues/2332</a> Can someone help here? Is there anyway to work around this behavior?<br class=""></blockquote><br class="">In this case that's different because the backend is inspecting the<br class="">body as it is coming and not rejecting the request based on the size<br class="">only. So I'm afraid there's no way to work around this behavior.<br class=""><br class="">As this is not a bug, we could introduce either a feature flag or a<br class="">VCL variable turned off by default to tolerate an early reset of the<br class="">request side of an HTTP/1 socket.<br class=""><br class="">You could join next bugwash on Monday to bring this to the team's<br class="">attention.<br class=""><br class="">Dridi<br class=""></div></div></blockquote></div><br class=""></div></body></html>