Re: archive not showing all attachements

On Sat, Mar 26, 2022 at 12:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> I recall an example recently [ digs... ] ah, here:
>
>
> https://www.postgresql.org/message-id/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com
>
> There is a patch in there, but it looks like the boundary line
> for the preceding section might be messed up?
>
>
IIUC...(I am by no means experienced here, and also haven't tried to
examine other good ones this evening. Just skimming RFC 1341 and trying to
make sense of what is shown)

Root uses a boundary of [42], which is structured as multipart/alternative
and has two mutually exclusive children:
Text Body (structured as text/plain)
HTML Body + Attachment (structured as a multipart/mixed [64]) - to make the
html (structured pointlessly? as multipart/related [86] and an embedded
text/html) and a attachment (structured as text/x-patch) independent

So a viewer displaying the text body alternative should not present the
attachment. But one presenting the HTML body would present the
attachment. Apparently the multipart/alternative section that makes text
and html mutually exclusive should ideally be in a multipart/mixed
container so that the shared attachment can be considered "mixed" with
whichever one of them is chosen.

We basically present the plain text version on our archive viewer so the
absence of the attachment is technically correct. Gmail for me defaults to
displaying html and so I too get the attachment download option.

Probably the archive should deal with the html branch in a better way than
a complete ignore. This does seem to indicate a need for at least somewhat
better handling of nested multipart messages - my advice in the prior email
to "let the user download and deal with it on their own" is probably
insufficient. The UI part of this, aside from agreement on what would be
nice to do, seems straight-forward enough; I don't have much feel for the
complexity of implementation though. We probably need to at least pull out
any explicit text attachments regardless of which branch we are showing.
Whether to extend that to any attachment type is probably easiest but worth
discussing. That would fall under "bug fix" for me. Converting the html
body branch into a download option would an improvement worth considering
along the lines of "everything is either displayed on the page or is an
attachment". Or, taken further, everything on the page (each part) can be
individually downloaded as content only.

Done for tonight...will probably explore a "good" example in light of my
understanding tomorrow.

David J.