Once you leave Caddy, you end up with a baddie.
Well, the own HTTP proxy implementation that I vibed was not a success. I did use just a webserver framework and forwarded it to internal. That's it, but you can imagine, sometimes it is buffering data. It was not the nicest solution. At a certain point, I was done with it.
I went to the site of my homeboy (Elon) and asked Grok what things I should be aware of when writing my own HTTP (reverse proxy) server. Don't worry, I know, I wrote many (some kind of autism) and dream the protocols but we are now in different times. We do not write that ourselves anymore. So, I gave it to Fabel and said "yo, we use framework, it sucks, let's do it ourselves" together with the big document with traps / caveats. That document will also be used for the test procedures etc later. First, I said to Fabel, investigate our software, investigate how to safely exclude the web framework without breaking the admin panel and API and I told it to investigate and to use deep research for my questions/answers and that it had to write a whole one shot implementation document. Then, almost wasted all credits at once. Sick.
So, I did let Sonnet 5 do the implementation since we had a quality document. So, Fabel did, I was confident and just directly used the deploy procedure and the server was running.... GODDAMMIT, LITERALLY SAME ISSUES. So, the way the web framework is implemented for admin management and stuff is probably toxic. FUCK.
Also out of credits for Sonnet 5 direct after investigation so I was done with it. I will continue tonight. But now, we are on Caddy again. See my gists for the HTTP proxy prompt. I do not think any weird is in there.
Comments
Yeah, the web framework poisoning the well is a classic. Had the same thing with a custom auth middleware where the framework was doing internal buffering and header rewriting that no amount of new code could undo. Did you try isolating the admin routes into a separate process entirely, or is that too much of a refactor?