A few more settings to look at: proxy.config.cache.max_doc_size proxy.config.http.max_post_size (if they are POSTs?)
miles On Fri, Sep 16, 2016 at 1:51 AM, Adam McCullough <[email protected]> wrote: > 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 > >
