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 <amccullo...@imvu.com> 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 <mlib...@apache.org> 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 <amccullo...@imvu.com>
>> 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
>
>

Reply via email to