A client too slow to send its request line and headers within SWWAF_CLIENT_REQUEST_TIMEOUT gets either no answer or an error answer from Go's server, mostly 400 Bad Request. Either way its connection is closed, nothing reaches the app, and no request log line is written. README.md ("Request log") and SPEC.md (size and time limits under "Configuration surface") said every such client gets no answer; they now say this.
The documents do not say which cut gets which answer: it depends on details of how Go's server reads a line, which are not smallwebwaf's to document.
SPEC.md's entry for SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES now says Go's HTTP server, not smallwebwaf, answers 431.
Deviation from the plan: the plan divided at the request line, 400 while it is unfinished and no answer after; the server does not divide there, so the text names the possible answers without a dividing rule.
Judgement call: the summaries of answers in the README ("What it does so far") and in SPEC.md (the bullet beginning "When a limit is passed before the response has started") gave 408 for any slow client; it is only for a slow body, so both now say so.
Model: opus-5-5
A client too slow to send its request line and headers within `SWWAF_CLIENT_REQUEST_TIMEOUT` gets either no answer or an error answer from Go's server, mostly `400 Bad Request`. Either way its connection is closed, nothing reaches the app, and no request log line is written. `README.md` ("Request log") and `SPEC.md` (size and time limits under "Configuration surface") said every such client gets no answer; they now say this.
The documents do not say which cut gets which answer: it depends on details of how Go's server reads a line, which are not `smallwebwaf`'s to document.
`SPEC.md`'s entry for `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` now says Go's HTTP server, not `smallwebwaf`, answers `431`.
- Deviation from the plan: the plan divided at the request line, `400` while it is unfinished and no answer after; the server does not divide there, so the text names the possible answers without a dividing rule.
- Judgement call: the summaries of answers in the README ("What it does so far") and in `SPEC.md` (the bullet beginning "When a limit is passed before the response has started") gave `408` for any slow client; it is only for a slow body, so both now say so.
Model: opus-5-5
SPEC.md, size and time limits under "Configuration surface", the bullet that begins "When a limit is passed before the response has started": it still gives 408 for "a client that is too slow". A client too slow to send its request line or headers never gets 408. It gets 400 or no answer, as the bullet this PR changes now says. This PR made the same correction in the README's summary but not here. Acceptable: 408 for a client too slow to send its body, as the README now says.
README.md ("Request log") and SPEC.md (the changed bullet): a line cut between its carriage return and line feed is answered 400. That holds for the request line, a header, and the empty line that ends the headers, because the server keeps the carriage return as part of the line. The new text does not name this case. Its example of no answer, "a client that stops at the end of a line", reads as covering a client that has sent the carriage return. Acceptable: name it among the 400 cases (for example "or a line cut between its carriage return and line feed"), and make the no-answer example a client that stops after a complete line end.
Model: opus-5-5
FAIL
1. `SPEC.md`, size and time limits under "Configuration surface", the bullet that begins "When a limit is passed before the response has started": it still gives `408` for "a client that is too slow". A client too slow to send its request line or headers never gets `408`. It gets `400` or no answer, as the bullet this PR changes now says. This PR made the same correction in the README's summary but not here. Acceptable: `408` for a client too slow to send its body, as the README now says.
2. `README.md` ("Request log") and `SPEC.md` (the changed bullet): a line cut between its carriage return and line feed is answered `400`. That holds for the request line, a header, and the empty line that ends the headers, because the server keeps the carriage return as part of the line. The new text does not name this case. Its example of no answer, "a client that stops at the end of a line", reads as covering a client that has sent the carriage return. Acceptable: name it among the `400` cases (for example "or a line cut between its carriage return and line feed"), and make the no-answer example a client that stops after a complete line end.
Model: opus-5-5
Rework: SPEC.md's summary of answers now gives 408 for a client too slow to send its body. README.md ("Request log") and SPEC.md name a line cut between its carriage return and line feed among the 400 cases, and the no-answer example is now a client that stops right after a line feed.
Model: opus-5-5
Rework: `SPEC.md`'s summary of answers now gives `408` for a client too slow to send its body.
`README.md` ("Request log") and `SPEC.md` name a line cut between its carriage return and line feed among the `400` cases, and the no-answer example is now a client that stops right after a line feed.
Model: opus-5-5
README.md ("Request log") and SPEC.md (the bullet beginning "Go's HTTP server, on which smallwebwaf is built"): the server reads a line in pieces of 4096 bytes, and when the time runs out right at the end of a piece, it closes the connection without an answer. So a request line cut before the end of its HTTP version, or a header cut before its colon, gets no answer when exactly 4096 bytes of it, or a multiple of 4096, have arrived and the last of them is not a carriage return, where the new text says 400. Acceptable: name that case among those that get no answer, in a plain sentence, or word the rule so it does not claim to hold for every cut. The commit message and the PR body state the same rule and need the same correction; the PR body is also over about 250 words.
Model: opus-5-5
FAIL
1. `README.md` ("Request log") and `SPEC.md` (the bullet beginning "Go's HTTP server, on which `smallwebwaf` is built"): the server reads a line in pieces of 4096 bytes, and when the time runs out right at the end of a piece, it closes the connection without an answer. So a request line cut before the end of its HTTP version, or a header cut before its colon, gets no answer when exactly 4096 bytes of it, or a multiple of 4096, have arrived and the last of them is not a carriage return, where the new text says `400`. Acceptable: name that case among those that get no answer, in a plain sentence, or word the rule so it does not claim to hold for every cut. The commit message and the PR body state the same rule and need the same correction; the PR body is also over about 250 words.
Model: opus-5-5
clawbot
changed title from README and SPEC say when a client too slow to send its request line or headers is answered 400 (closes #138) to README and SPEC say a client too slow to send its request line and headers may get 400 (closes #138)2026-10-20 13:55:40 +02:00
Rework: README.md ("Request log") and SPEC.md no longer list which cut gets which answer; they now say a client too slow to send its request line and headers gets either no answer or, depending on how much of them had arrived, 400 Bad Request, and that either way its connection is closed, nothing reaches the app, and no request log line is written.
The commit message and the PR body say the same, and the PR body is shorter.
Model: opus-5-5
Rework: `README.md` ("Request log") and `SPEC.md` no longer list which cut gets which answer; they now say a client too slow to send its request line and headers gets either no answer or, depending on how much of them had arrived, `400 Bad Request`, and that either way its connection is closed, nothing reaches the app, and no request log line is written.
The commit message and the PR body say the same, and the PR body is shorter.
Model: opus-5-5
README.md, "What it does so far", the bullet beginning "Enforces the timeouts and the size limits below", and SPEC.md, the bullet beginning "When a limit is passed before the response has started": both still say that any limit passed before the response has started gets smallwebwaf's own answer. A client too slow to send its request line and headers within SWWAF_CLIENT_REQUEST_TIMEOUT passes a limit before any response, and gets no answer or 400 Bad Request from Go's server, as the new text in "Request log" and in the bullet beginning "Go's HTTP server" says. Acceptable: those two sentences speak only of limits passed after the request line and headers have been read, or they say that a client too slow to send them gets no answer or 400 from Go's server.
Judgement call: the start of both sentences was there before this PR; it counts because this PR rewrote their clause about slow clients, for the case #138 covers.
Model: opus-5-5
FAIL
1. `README.md`, "What it does so far", the bullet beginning "Enforces the timeouts and the size limits below", and `SPEC.md`, the bullet beginning "When a limit is passed before the response has started": both still say that any limit passed before the response has started gets `smallwebwaf`'s own answer. A client too slow to send its request line and headers within `SWWAF_CLIENT_REQUEST_TIMEOUT` passes a limit before any response, and gets no answer or `400 Bad Request` from Go's server, as the new text in "Request log" and in the bullet beginning "Go's HTTP server" says. Acceptable: those two sentences speak only of limits passed after the request line and headers have been read, or they say that a client too slow to send them gets no answer or `400` from Go's server.
Judgement call: the start of both sentences was there before this PR; it counts because this PR rewrote their clause about slow clients, for the case https://git.eeqj.de/sneak/smallwebwaf/issues/138 covers.
Model: opus-5-5
In README.md and SPEC.md, the summaries of smallwebwaf's own answers now speak only of limits passed after a request's line and headers have been read. SPEC.md's entry for SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES now says Go's HTTP server answers 431, as its later bullet on Go's server already said.
Model: opus-5-5
In `README.md` and `SPEC.md`, the summaries of `smallwebwaf`'s own answers now speak only of limits passed after a request's line and headers have been read.
`SPEC.md`'s entry for `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` now says Go's HTTP server answers `431`, as its later bullet on Go's server already said.
Model: opus-5-5
README.md ("Request log") and SPEC.md (the bullet beginning "Go's HTTP server, on which smallwebwaf is built"): the new sentence says a client too slow to send its request line and headers gets either no answer or 400 Bad Request. That is untrue for one cut. The Go version the image is built with refuses a request with more than 500 header lines, and counts a header line the timeout cuts short as one. So a client that has sent 500 header lines and is cut partway into the next is answered 431 when SWWAF_CLIENT_REQUEST_TIMEOUT runs out. Acceptable: a sentence that holds for every cut, for example that such a client gets either no answer or an error answer from the server, mostly 400 Bad Request.
PR body: it does not mention that SPEC.md's entry for SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES now says Go's HTTP server, not smallwebwaf, answers 431. Acceptable: one line in the PR body saying so.
Judgement call: finding 1 is what the image does (Go 1.27). A binary built with Go 1.26, as make build is on a host with the version go.mod names, has no limit on header lines and gives no answer for that cut. The image is what ships.
Model: opus-5-5
FAIL
1. `README.md` ("Request log") and `SPEC.md` (the bullet beginning "Go's HTTP server, on which `smallwebwaf` is built"): the new sentence says a client too slow to send its request line and headers gets either no answer or `400 Bad Request`. That is untrue for one cut. The Go version the image is built with refuses a request with more than 500 header lines, and counts a header line the timeout cuts short as one. So a client that has sent 500 header lines and is cut partway into the next is answered `431` when `SWWAF_CLIENT_REQUEST_TIMEOUT` runs out. Acceptable: a sentence that holds for every cut, for example that such a client gets either no answer or an error answer from the server, mostly `400 Bad Request`.
2. PR body: it does not mention that `SPEC.md`'s entry for `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` now says Go's HTTP server, not `smallwebwaf`, answers `431`. Acceptable: one line in the PR body saying so.
Judgement call: finding 1 is what the image does (Go 1.27). A binary built with Go 1.26, as `make build` is on a host with the version `go.mod` names, has no limit on header lines and gives no answer for that cut. The image is what ships.
Model: opus-5-5
A client too slow to send its request line and headers within
SWWAF_CLIENT_REQUEST_TIMEOUT gets either no answer or an error answer
from Go's server, mostly 400 Bad Request; either way its connection is
closed, nothing reaches the app, and no request log line is written.
The README's "Request log" and SPEC's size and time limits said such a
client always gets no answer. Both documents' summaries of
smallwebwaf's own answers now cover only limits passed after the
request line and headers have been read, and give 408 only for a slow
body; SPEC names Go's server as the one answering 431.
Model: opus-5-5
clawbot
changed title from README and SPEC say a client too slow to send its request line and headers may get 400 (closes #138) to README and SPEC say a client too slow to send its request line and headers may get an error answer (closes #138)2026-10-20 16:20:05 +02:00
README.md ("Request log") and SPEC.md now say a client too slow to send its request line and headers gets either no answer or an error answer from Go's server, mostly 400 Bad Request. The PR body now says that SPEC.md's entry for SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES names Go's HTTP server, not smallwebwaf, as the one answering 431.
Model: opus-5-5
`README.md` ("Request log") and `SPEC.md` now say a client too slow to send its request line and headers gets either no answer or an error answer from Go's server, mostly `400 Bad Request`. The PR body now says that `SPEC.md`'s entry for `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` names Go's HTTP server, not `smallwebwaf`, as the one answering `431`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A client too slow to send its request line and headers within
SWWAF_CLIENT_REQUEST_TIMEOUTgets either no answer or an error answer from Go's server, mostly400 Bad Request. Either way its connection is closed, nothing reaches the app, and no request log line is written.README.md("Request log") andSPEC.md(size and time limits under "Configuration surface") said every such client gets no answer; they now say this.The documents do not say which cut gets which answer: it depends on details of how Go's server reads a line, which are not
smallwebwaf's to document.SPEC.md's entry forSWWAF_CLIENT_REQUEST_HEADER_MAX_BYTESnow says Go's HTTP server, notsmallwebwaf, answers431.400while it is unfinished and no answer after; the server does not divide there, so the text names the possible answers without a dividing rule.SPEC.md(the bullet beginning "When a limit is passed before the response has started") gave408for any slow client; it is only for a slow body, so both now say so.Model: opus-5-5
FAIL
SPEC.md, size and time limits under "Configuration surface", the bullet that begins "When a limit is passed before the response has started": it still gives408for "a client that is too slow". A client too slow to send its request line or headers never gets408. It gets400or no answer, as the bullet this PR changes now says. This PR made the same correction in the README's summary but not here. Acceptable:408for a client too slow to send its body, as the README now says.README.md("Request log") andSPEC.md(the changed bullet): a line cut between its carriage return and line feed is answered400. That holds for the request line, a header, and the empty line that ends the headers, because the server keeps the carriage return as part of the line. The new text does not name this case. Its example of no answer, "a client that stops at the end of a line", reads as covering a client that has sent the carriage return. Acceptable: name it among the400cases (for example "or a line cut between its carriage return and line feed"), and make the no-answer example a client that stops after a complete line end.Model: opus-5-5
33b4d931dftobaa90d7625Rework:
SPEC.md's summary of answers now gives408for a client too slow to send its body.README.md("Request log") andSPEC.mdname a line cut between its carriage return and line feed among the400cases, and the no-answer example is now a client that stops right after a line feed.Model: opus-5-5
clawbot referenced this pull request2026-10-20 13:39:35 +02:00
FAIL
README.md("Request log") andSPEC.md(the bullet beginning "Go's HTTP server, on whichsmallwebwafis built"): the server reads a line in pieces of 4096 bytes, and when the time runs out right at the end of a piece, it closes the connection without an answer. So a request line cut before the end of its HTTP version, or a header cut before its colon, gets no answer when exactly 4096 bytes of it, or a multiple of 4096, have arrived and the last of them is not a carriage return, where the new text says400. Acceptable: name that case among those that get no answer, in a plain sentence, or word the rule so it does not claim to hold for every cut. The commit message and the PR body state the same rule and need the same correction; the PR body is also over about 250 words.Model: opus-5-5
baa90d7625to2387bd4f3aREADME and SPEC say when a client too slow to send its request line or headers is answered 400 (closes #138)to README and SPEC say a client too slow to send its request line and headers may get 400 (closes #138)Rework:
README.md("Request log") andSPEC.mdno longer list which cut gets which answer; they now say a client too slow to send its request line and headers gets either no answer or, depending on how much of them had arrived,400 Bad Request, and that either way its connection is closed, nothing reaches the app, and no request log line is written.The commit message and the PR body say the same, and the PR body is shorter.
Model: opus-5-5
FAIL
README.md, "What it does so far", the bullet beginning "Enforces the timeouts and the size limits below", andSPEC.md, the bullet beginning "When a limit is passed before the response has started": both still say that any limit passed before the response has started getssmallwebwaf's own answer. A client too slow to send its request line and headers withinSWWAF_CLIENT_REQUEST_TIMEOUTpasses a limit before any response, and gets no answer or400 Bad Requestfrom Go's server, as the new text in "Request log" and in the bullet beginning "Go's HTTP server" says. Acceptable: those two sentences speak only of limits passed after the request line and headers have been read, or they say that a client too slow to send them gets no answer or400from Go's server.Judgement call: the start of both sentences was there before this PR; it counts because this PR rewrote their clause about slow clients, for the case #138 covers.
Model: opus-5-5
2387bd4f3atode36f24ed5In
README.mdandSPEC.md, the summaries ofsmallwebwaf's own answers now speak only of limits passed after a request's line and headers have been read.SPEC.md's entry forSWWAF_CLIENT_REQUEST_HEADER_MAX_BYTESnow says Go's HTTP server answers431, as its later bullet on Go's server already said.Model: opus-5-5
FAIL
README.md("Request log") andSPEC.md(the bullet beginning "Go's HTTP server, on whichsmallwebwafis built"): the new sentence says a client too slow to send its request line and headers gets either no answer or400 Bad Request. That is untrue for one cut. The Go version the image is built with refuses a request with more than 500 header lines, and counts a header line the timeout cuts short as one. So a client that has sent 500 header lines and is cut partway into the next is answered431whenSWWAF_CLIENT_REQUEST_TIMEOUTruns out. Acceptable: a sentence that holds for every cut, for example that such a client gets either no answer or an error answer from the server, mostly400 Bad Request.SPEC.md's entry forSWWAF_CLIENT_REQUEST_HEADER_MAX_BYTESnow says Go's HTTP server, notsmallwebwaf, answers431. Acceptable: one line in the PR body saying so.Judgement call: finding 1 is what the image does (Go 1.27). A binary built with Go 1.26, as
make buildis on a host with the versiongo.modnames, has no limit on header lines and gives no answer for that cut. The image is what ships.Model: opus-5-5
de36f24ed5to4788c06380README and SPEC say a client too slow to send its request line and headers may get 400 (closes #138)to README and SPEC say a client too slow to send its request line and headers may get an error answer (closes #138)README.md("Request log") andSPEC.mdnow say a client too slow to send its request line and headers gets either no answer or an error answer from Go's server, mostly400 Bad Request. The PR body now says thatSPEC.md's entry forSWWAF_CLIENT_REQUEST_HEADER_MAX_BYTESnames Go's HTTP server, notsmallwebwaf, as the one answering431.Model: opus-5-5
PASS
Model: opus-5-5