Skip Menu |

This queue is for tickets about the Net-IMAP-Server CPAN distribution.

Report information
The Basics
Id: 59676
Status: resolved
Priority: 0/
Queue: Net-IMAP-Server

People
Owner: Nobody in particular
Requestors: jettero [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: fetch response seems to have a little extra response after the response
Please see the attached log. I'm trying to read RFC3501 to see if this is even incorrect or intentional. It seems like it's probably not what you meant. I get the FETCH response, like I expect, but it's also followed by a second response for each message that has just the flags in it. This happens whether I query the flags or not. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
Subject: file.log
C(t::Connection=HASH(0x1ccbff0),working,INBOX): 5 FETCH 1:* (UID BODY[HEADER.FIELDS (DATE FROM SUBJECT)]) S(t::Connection=HASH(0x1ccbff0),working,INBOX): * 1 FETCH (UID 1000 BODY[HEADER.FIELDS (DATE FROM SUBJECT)] {102}%0D Date: Sat, 24 Jul 2010 10:01:09 -0400%0D From: Paul Miller <jettero@cpan.org>%0D Subject: test message%0D %0D FLAGS (\Recent \Seen)) S(t::Connection=HASH(0x1ccbff0),working,INBOX): * 2 FETCH (UID 1001 BODY[HEADER.FIELDS (DATE FROM SUBJECT)] {95}%0D Date: Sat, 24 Jul 2010 10:04:12 -0400%0D From: Paul Miller <jettero@cpan.org>%0D Subject: test2%0D %0D FLAGS (\Recent \Seen)) S(t::Connection=HASH(0x1ccbff0),working,INBOX): * 1 FETCH (FLAGS (\Recent \Seen)) S(t::Connection=HASH(0x1ccbff0),working,INBOX): * 2 FETCH (FLAGS (\Recent \Seen)) S(t::Connection=HASH(0x1ccbff0),working,INBOX): 5 OK FETCH COMPLETED
Subject: Re: [rt.cpan.org #59676] fetch response seems to have a little extra response after the response
Date: Wed, 28 Jul 2010 12:38:13 -0400
To: bug-Net-IMAP-Server <bug-net-imap-server [...] rt.cpan.org>
From: Alex Vandiver <alex [...] chmrr.net>
At Sat Jul 24 12:56:19 -0400 2010, Paul Miller via RT wrote: Show quoted text
> Please see the attached log. I'm trying to read RFC3501 to see if this > is even incorrect or intentional. It seems like it's probably not what > you meant. > > I get the FETCH response, like I expect, but it's also followed by a > second response for each message that has just the flags in it. This > happens whether I query the flags or not. >
This is because fetching the BODY has caused the \Seen flag to be set, which the server is notifying you of -- per section 6.4.5, under "BODY": "The \Seen flag is implicitly set; if this causes the flags to change, they SHOULD be included as part of the FETCH responses." And section 7.4.2, "FETCH response", states (emphasis mine): The FETCH response returns data about a message to the client. The data are pairs of data item names and their values in parentheses. This response occurs as the result of a FETCH or STORE command, as well as by unilateral server decision (e.g., *flag updates*). From 2.2.2, desribing unilateral server data: Server data MAY be sent as a result of a client command, or MAY be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally. So, my parsing of this is that it is absolutely acceptible per the RFC. I agree that it's perhaps no the most expected form, nor is it what Dovecot or Cyrus do. I'll look into fixing it, but it's lower-priority for me. - Alex -- Networking -- only one letter away from not working
Subject: Re: [rt.cpan.org #59676] fetch response seems to have a little extra response after the response
Date: Wed, 28 Jul 2010 12:50:45 -0400
To: bug-Net-IMAP-Server <bug-net-imap-server [...] rt.cpan.org>
From: Alex Vandiver <alex [...] chmrr.net>
At Wed Jul 28 12:38:23 -0400 2010, Alex Vandiver via RT wrote: Show quoted text
> So, my parsing of this is that it is absolutely acceptible per the > RFC. I agree that it's perhaps no the most expected form, nor is it > what Dovecot or Cyrus do. I'll look into fixing it, but it's > lower-priority for me.
What I was missing was that the FLAGS were being reported twice -- which makes this a three-character fix (plus comments, etc). Pushed as 278a9f5. I'll roll a release shortly. - Alex -- Networking -- only one letter away from not working