> On Oct 17, 2016, at 1:03 PM, Adam McCullough wrote:
>
> Apologies for the necro-post, but I wanted to follow up on this for posterity.
>
> It turns out that the bottleneck was not ATS at all. By itself, ATS seems to
> have trouble with characters longer than 65,536 chars. However, the issue
Apologies for the necro-post, but I wanted to follow up on this for
posterity.
It turns out that the bottleneck was not ATS at all. By itself, ATS seems
to have trouble with characters longer than 65,536 chars. However, the
issue I was running into was because another part of our stack was throwin
> On Sep 15, 2016, at 5:57 PM, Adam McCullough 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 terribl
Miles -
Sadly, neither of those settings had any effect. I'm beginning to suspect
this is something of a lost cause, at least in the 6.1,1 version I'm
running.
Thanks,
Adam
On Mon, Sep 19, 2016 at 11:45 PM, Adam McCullough
wrote:
> Miles -- I'll take a look at those settings and see if they c
Miles -- I'll take a look at those settings and see if they change anything.
Reindl -- I absolutely see your point, but that's not really within the
scope of what I can attempt. I'm trying to stand up a replacement caching
proxy, not refactor the backing app.
Not saying you're wrong, just that it
Am 19.09.2016 um 20:23 schrieb Miles Libbey:
A few more settings to look at:
proxy.config.cache.max_doc_size
proxy.config.http.max_post_size (if they are POSTs?)
that's all nice *but* a URL longer than 8K is a fractal of bad design of
whatever applications doing that instead using POST for a
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 wrote:
> Thanks for the reply!
>
> Interesting that the cookie doesn't affect things. Also a good idea to have
> the origin
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 t
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..5'`" H "Cookie: x=`perl -e 'print "x" for 1..5'`"
which was accepted.
