GNOME Bugzilla – Bug 202529
imap commands can be too long
Last modified: 2002-01-15 18:47:45 UTC
Select a good amount of messages, say a few thousand. Hit Delete. Error while performing opration: Unexpected response from IMAP server: A00295 BAD Command line too long
Oh, there was a bug that I've fixed that was making it say 1,2,3,4,5,6,7,... instead of 1:1000 when setting flags, so that's probably what caused the bug in the case you mentioned, although you could still trigger it by deleting a large number of non-contiguous messages.
vlad: can you still duplicate this? I'm going to mark FIXED as per Dan's comment, but we can re-open easily.
yeah, so the problem here was definitely non-contigous messages (in this case, only bugzilla bug changes were moved, while new bugs and 'real' mail were left untouched.) I've put in nfs the trace of the error file. I'm also upping the priority a touch, since it makes the program unusable and doesn't deal with the error message generated well at all. :/
doh. nfs location is /nfs/louie/bug_2529_trace.txt .
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
From Courier-imapd sources: #define IT_MAX_ATOM_SIZE 16384 (IT == short for IMAP_TOKEN it seems) not sure what uw.imapd uses as it's maximum token size... this is just plain sad.
reassigning to me for 1.2 I've actually fixed most of this, there is only 1 location that still needs fixing afaik which is imap_update_summary() in camel-imap-folder.c Well, "fixed" in so far as it will limit uid-set tokens to a pre-defined size. As far as I know, no other tokens can get large enough to matter. I guess we may still have to limit the entire command-line limit to ~8k, but afaik - this shouldn't be an issue if we limit the uid-set size to something reasonable. rfc2683 suggests 1k but I think we can actually get away with something larger, like maybe 4-6k. Currently I've defined UID_SET_LIMIT to -1 (aka unlimited) but we can either hard-code this value to whatever we want or maybe special-case the value based on the server impl? >:-) For Courier, we know that a token must be <16k but that the command-line is not limited. For UW, we know that the token size doesn't matter so long as the entire command-line is <8k For an unknown server, we could limit each token to say 1k so that we are sure to work... and if we ever write Camel-imapd, we can limit it to some other size (or unlimited if we write camel-imapd to not impose any limitations)
I've just fixed imap_update_summary to respect UID_SET_LIMIT now. So this is the last of the functions that needed updating. The only part of this bug that can possibly still go wrong is maybe a command-line could be too long despite the limitation of the uid-set token. The only place I can think of that could possibly cause a command-line to be too long now is the SEARCH command for like BODY and HEADER searches (since they take user input). But this can't possibly be fixed until we use Zucchi's ImapEngine so I am now marking this as a duplicate of "imap rewrite"
*** This bug has been marked as a duplicate of 216927 ***