вт, 20 янв. 2026 г. в 08:28, Willy Tarreau <[email protected]>: > On Tue, Jan 20, 2026 at 08:17:20AM +0100, ???? ??????? wrote: > > ??, 20 ???. 2026 ?. ? 08:10, Willy Tarreau <[email protected]>: > > > > > Hi Ilya, > > > > > > On Mon, Jan 19, 2026 at 09:46:36PM +0100, Ilia Shipitsin wrote: > > > > From: "copilot-swe-agent[bot]" < > > > [email protected]> > > > > > > > > Co-authored-by: chipitsine < > [email protected]> > > > > > > I don't know if it's you or a bot doing it on you, but this is useless > at > > > best, or possibly even dangerous: > > > > > > > from the legal point of view it might be dangerous not to include. > > I don't care about including the tag or not, I'm really speaking about > the finality of it. > > > > > --- a/examples/errorfiles/400.http > > > > +++ b/examples/errorfiles/400.http > > > > @@ -1,9 +1,8 @@ > > > > HTTP/1.0 400 Bad request > > > > -Cache-Control: no-cache > > > > > > Probably not a good idea to make error pages cacheable, that's the best > > > way to make a site appear unavailable even after full recovery. > > > > > > > I read RFC and those responses are not cacheble: 400, 401, 403, 407, 408, > > 413, 421, 422, 425, 429, 431, 500, 502, 503, 504 > > > > either with or without Cache-Control > > OK but not all agents are 100% aware of what's permitted and what's not, > and taking conservative approaches on error paths is super important. It > can literally take months to years before discovering that some tools > mistakenly cache a 503 or a 403, just because these are pretty rare, and > because users are rarely able to contact a site which appears to be down > to report an issue. > > > > Also, like most often with such bots, there's zero explanation in the > > > commit message about the intent and the purpose of the change. I'd > > > rather see you post yourself patches that you authored with the help > > > of such stupid bots, rather than let these bots post patches for you > > > and discredit you. Just my two cents. > > > > > > > use of any tool like vs code or automatic testing instead of code review > > can discredit me, it is something that we live with > > OK but at least here it didn't act well, at least not as well as you > normally do. >
honestly, it did things in the way I meant - i.e. add Cache-Control only to cacheable responses and do not add to those known as non cacheable. The question was to keep or to hide copilot assistance, which I think from the legal point of view is a bad idea to hide. As for accident line ending replacement, I likely could do the same because of the settings of my editor. not intentionally, but easy to overlook. > > Willy >
