Thanks for the reply! Interesting that the cookie doesn't affect things. Also a good idea to have the origin generate a giant response, I'll have to see if I can cook that up somehow.
The URLs I'm dealing with are JSON structures that are base64 encoded. I'm fairly certain that both the URL and the headers matter, though, because I discovered that if I have a URL that's ~7K long, it will work if I just curl the URL, and it will work if I hit it in an incognito browser window, but will fail in a regular session, and also fail if I use the curl command that the network analyzer gives me in the regular session. It fails with a 400, as I mentioned earlier. Another piece of information: If I hit it with a URL of about 7-8K in length, it goes into the traffic log I've set up for ATS (netscape-extended2 format, specifically). The full URL is present, and it shows that it responded with a 400, along with all the other particulars in the log format. If I hit the server with a URL of around 10K in length, the server still responds with a 400, but it doesn't go into the log at all. It's completely absent. Adam On Thu, Sep 15, 2016 at 9:54 PM, Miles Libbey <[email protected]> wrote: > I know this isn't particularly helpful, but the other day I tested a > Cookie Length of >65KB, and it worked on our system. I just tried a > url like > curl -x localhost:80 "http://example.com/?foo=`perl -e 'print "x" for > 1..50000'`" H "Cookie: x=`perl -e 'print "x" for 1..50000'`" > which was accepted. > > $ traffic_ctl config match header_max_size > proxy.config.http.request_header_max_size: 131072 > proxy.config.http.response_header_max_size: 131072 > > Oh. When I made the request too big, I got > HTTP/1.0 400 Invalid HTTP Request > I don't have a origin that gives a gigantic response though to test. > > Wonder if there is a way to isolate the origin server from ATS? > > miles > > On Thu, Sep 15, 2016 at 5:57 PM, Adam McCullough <[email protected]> > wrote: > > Hello! > > > > I'm running into a problem with ATS. I'm using it as a proxy to an > internal > > endpoint, which regularly takes very long URLs -- 3KiB URLs are normal, > I've > > seen as long as 11KiB. > > > > ATS doesn't seem to handle this terribly well. I've done some > experimenting > > and found that ATS tends to respond with a HTTP 400 Invalid Client > Request > > when given a request where the URL + Header/Cookie data goes above about > 8 > > KiB. > > > > This does not overly surprise me, since a URL that's longer than 8K is, > in > > most circumstances, absurd. However, it's a necessairy feature for the > app > > I'm tasked with deploying. > > > > So, I have two questions. 1 - is my suspicion that I'm overflowing some > 8K > > sized buffer somewhere correct, and 2 - if so, is there an easy way to > grow > > this buffer to allow for very long requests? > > > > I've found both proxy.config.http.request_header_max_size and > > proxy.config.http.response_header_max_size and set them to 524288 (512 * > > 1024) as an attempt to troubleshoot, but this did not seem to help. > > > > Many thanks, > > > > Adam >
