77 lines
2.9 KiB
Plaintext
77 lines
2.9 KiB
Plaintext
MBOX-Line: From norman at apache.org Fri Apr 15 11:17:20 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Norman Maurer <norman@apache.org>
|
|
Date: Fri Jun 8 12:34:45 2018
|
|
Subject: [Imap-protocol] FETCH Response
|
|
In-Reply-To: <alpine.OSX.2.00.1104151032550.797@hsinghsing.panda.com>
|
|
References: <BANLkTi=fFBXLWaJ9bnnjm2dO0uYJPGGnkQ@mail.gmail.com>
|
|
<alpine.OSX.2.00.1104151032550.797@hsinghsing.panda.com>
|
|
Message-ID: <BANLkTi=p5s7Vnri5p44Yuzq2M-Y9x-HWAw@mail.gmail.com>
|
|
|
|
Hi Mark,
|
|
|
|
this was exactly what I was refer to, and the answer I needed. Sorry
|
|
the \ where there by mistake..
|
|
|
|
Thanks again for your help :)
|
|
|
|
Bye,
|
|
Norman
|
|
|
|
|
|
2011/4/15 Mark Crispin <mrc+imap@panda.com>:
|
|
> It took me a while to figure out what you were asking in your example, as
|
|
> you omitted some important information: specifically, the BODYSTRUCTURE
|
|
> that identified the type/subtype/encoding of message part 3. ?Also,
|
|
> where did those spurious \ in the server responses come from?
|
|
>
|
|
> Anyway, I think that your answer is as follows:
|
|
>
|
|
> The BODY section specifiers HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and
|
|
> TEXT only apply to message parts of type MESSAGE/RFC822. ?Implicitly, the
|
|
> entire message (the top level) is typed MESSAGE/RFC822.
|
|
>
|
|
> Your example presumably shows a TEXT/HTML message part with encoding
|
|
> BASE64. ?At least, the BODY[3] contents appeared to be BASE64, and when
|
|
> put through a BASE64 decoder came up with a short HTML document.
|
|
>
|
|
> In other words, HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT are all
|
|
> meaningless for BODY[3] in this example. ?The appropriate server behavior
|
|
> is:
|
|
>
|
|
> C: A18 FETCH 1 BODY[3.HEADER]
|
|
> S: * 1 FETCH (BODY[3.HEADER] "")
|
|
> S: A18 OK that was a silly thing for you to do!
|
|
> C: A19 FETCH 1 BODY[3.TEXT]
|
|
> S: * 1 FETCH (BODY[3.TEXT] "")
|
|
> S: A19 OK that was a silly thing for you to do!
|
|
>
|
|
> As a matter of good design, you should always use an zero-length quoted
|
|
> string, rather than a zero-length literal, to represent the empty string.
|
|
> Of course, implementations MUST accept either form.
|
|
>
|
|
> The reason why you don't have a blank line in the 3.HEADER fetch is that
|
|
> there is no "message" (it is a TEXT/HTML, not a MESSAGE/RFC822) and thus
|
|
> if you are substituting an empty string the "message which has no body and
|
|
> no blank line" rule applies.
|
|
>
|
|
> If I were to do things over today, I would have required:
|
|
>
|
|
> C: A18 FETCH 1 BODY[3.HEADER]
|
|
> S: A18 BAD meaningless to fetch header for type TEXT/HTML
|
|
> C: A19 FETCH 1 BODY[3.TEXT]
|
|
> S: A19 BAD meaningless to fetch header for type TEXT/HTML
|
|
>
|
|
> It's historical as to why meaningless text fetches return the empty string
|
|
> rather than a BAD; there were good reasons once upon a time but those
|
|
> reasons have long since been rendered moot. ?A related history is why
|
|
> BODY[1] and BODY[TEXT] are equivalent for a non-MIME message.
|
|
>
|
|
> -- Mark --
|
|
>
|
|
> http://panda.com/mrc
|
|
> Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
> Liberty is a well-armed sheep contesting the vote.
|
|
>
|
|
|