compatible with non-compliant responses with excessive SPACE

emersion / go-imap

📥 An IMAP library for clients and servers

MIT License

2.02k stars 288 forks source link

compatible with non-compliant responses with excessive SPACE #596

Closed qjebbs closed 4 months ago

qjebbs commented 4 months ago

This PR improves compatibility with non-compliant servers, by skipping excessive SPACE between elements and the trailing SPACE

imap.exmail.qq.com: * CAPABILITY IMAP4<SP>IMAP4rev1<SP><CRLF>
smtp-n.global-mail.cn: * SEARCH<SP><CRLF>

It works good in my env, the only question that comes to mind is whether SP(), ExpectSP() needs to be renamed (e.g.: LSP() for leading Space) for method semantics reasons.

related: #571 #540

emersion commented 4 months ago

Hm, I'd prefer to only diverge from the standard where it's actually needed by some servers. For instance if you haven't hit servers sending <SP><SP> I'd prefer to keep rejecting that. Otherwise we might be seeing more servers breaking the standard in more new ways…

emersion commented 4 months ago

It works good in my env, the only question that comes to mind is whether SP(), ExpectSP() needs to be renamed (e.g.: LSP() for leading Space) for method semantics reasons.

I'd prefer not to reflect non-standard server quirks in the API.

qjebbs commented 4 months ago

Hm, I'd prefer to only diverge from the standard where it's actually needed by some servers. For instance if you haven't hit servers sending <SP><SP> I'd prefer to keep rejecting that. Otherwise we might be seeing more servers breaking the standard in more new ways…

Updated.

Your opinion makes sense from a library maintainer's perspective, but from users' perspective like me, by solving all potential issues I can foresee, I can maximize the compatibility of the program (including the lib it uses), not to break down on new servers time to time. That's what I did in the first two commits.