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