On 05 Apr 2016, at 11:33, Chris Laif <chris.l...@googlemail.com> wrote:
>
> I've captured some requests and they look like this (some parts
> changed due to privacy concerns):
>
> GET
> /solr/select?fl=uid,score&rows=439&sort=uid+asc&q={!lucene+q.op%3dAND}hdr:%3c56fxxxx3a6.7080...@domain.de%3e+OR+hdr:%3c664dcdxxxxx1a4facd8b7922c495...@czchows1356.prg%5c-domain.com%3e+OR+hdr:%3c00cxxxxxde3$70ad7880$52
> ... (many many more OR hdrs)
> &fq=%2Bbox:f696f93xxxxxx6e+%2Buser:u...@domain.de HTTP/1.1
>
> The total request size is 31708 bytes and it contains many (hundreds?)
> of 'OR hdrs' (side note: I wonder which client action triggers these
> kind of requests, maybe the user selected hundreds of mails for
> search?)
I bet this is the weird iOS client stupidity where they for some weird reason
started issuing commands like:
SEARCH OR HEADER Message-ID id1 OR HEADER Message-ID id2 OR HEADER Message-ID
id3 ...
With the entire command about ~32 kB. It does it for every single message in
the folder. Why not simply FETCH 1:* HEADER.FIELDS[Message-ID] and do the
matching itself..
> I _think_ this is a problem of the URL length / max http header size.
> (Debian Jessie) Tomcat7 very likely does not accept more than 32kb
> data in a request.
>
> I wonder if Dovecot should limit SOLR requests to a specific size and
> deny long requests with an imap error (?)
Or just issue multiple Solr requests.. In any case, troublesome.. Could those
limits be just increased in Tomcat?
