https://bz.apache.org/bugzilla/show_bug.cgi?id=66177
Bug ID: 66177
Summary: option for sending 408 on keepalive timeout in event
MPM?
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: enhancement
Priority: P2
Component: mpm_event
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
(while this applies to !event, it is trivial to implement for sync
mpms/requests in ap_read_request())
In POST-heavy environments, browsers can hit hard to troubleshoot keepalive
races. If the POST is an XHR/fetch, it's hard to interpret the error and
determine if the request can be retried by any layer.
One solution to this problem exists in chrome, where a 408 response is
considered retryable (because it's clear the body wasn't processed)
https://bugs.chromium.org/p/chromium/issues/detail?id=377581
https://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc#l1004
While many servers send a 408 if the initial request never arrives, I couldn't
find any sign of them doing the same for keepalive requests (haproxy, nginx,
gws, apache).
It seems a bit tricky to incorporate into event, since it is an additional
non-poll case where we'd want to push2worker, then do a tiny bit of work
similar to ap_read_request withotu actually reading, then finally
process_socket on the same worker in CONN_STATE_LINGER
I wonder if defer_linger_chain could be made something more general and this
special 408 behavior wouldthen be a new state to handle in process_socket that
transitions to CONN_STATE_LINGER?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
