-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge support for COMPRESS extension #342
Conversation
Codecov Report
@@ Coverage Diff @@
## master #342 +/- ##
=========================================
- Coverage 73.65% 72.1% -1.56%
=========================================
Files 32 33 +1
Lines 3519 3617 +98
=========================================
+ Hits 2592 2608 +16
- Misses 638 715 +77
- Partials 289 294 +5
Continue to review full report at Codecov.
|
On I18NLEVEL=1 vs 1+2 support: Client support for I18NLEVEL altogether is not very impressive according to DCS and nobody seems to care about I18NLEVEL=2. |
@emersion What's your opinion on ID extension? Not worth merging? |
server/cmd_noauth_test.go
Outdated
@@ -30,7 +30,7 @@ func testServerTLS(t *testing.T) (s *server.Server, c net.Conn, scanner *bufio.S | |||
|
|||
io.WriteString(c, "a001 CAPABILITY\r\n") | |||
scanner.Scan() | |||
if scanner.Text() != "* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR STARTTLS LOGINDISABLED" { | |||
if scanner.Text() != "* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR SPECIAL-USE CHILDREN UNSELECT COMPRESS=DEFLATE APPENDLIMIT STARTTLS LOGINDISABLED" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can add constants for these? So that we only need to update them once when adding a new extension?
When this is merged, we need to create issues if the client or server side of an extension is missing. |
Yeah, I'd prefer to leave it out if possible. |
Not sure what is better for I18NLEVEL. Is just having a variable Server.EnableI18N enough or do we want to check backend I18N "awareness" using some interface like |
Oh, you know, lets get that merged and then I will continue working on it when I will have more time. |
deflate.go
Outdated
// | ||
// It is used by COMPRESS extension implementation and it not a part of the | ||
// library API. Do not use it. | ||
func CreateDeflateConn(c net.Conn, level int) (net.Conn, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we expose this to users? Or should we define this in an internal
package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not seeing a reason to keep it public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
be45b1e
to
a48b2ea
Compare
|
Advertising SPECIAL-USE without backend support is valid - it will just look like there MAY be special-use mailboxes but there are currently none. CREATE-SPECIAL-USE is a separate capability. |
OK that makes sense |
RFC 3348 seems to be pretty lax regarding attributes too:
So we probably can get away with it without bothering much. |
7339790
to
2d90431
Compare
Holding off this PR for now because merging it would break the API: some extensions might get added twice (built-in + external). |
What is the effect of adding an external extension when it is already supported directly? Can we add a compatibility hack that would just ignore the external extension in this case? |
I wonder if it's better to let external extensions overwrite built-in extensions (and de-dup our caps), or make if it's better to make |
The idea with some builtin extensions is that they are builtin because their support requires special changes to go-imap 'core' source code. If we let external extensions override such changes we need to have a whole bunch of Along the way, we considered phasing out the extension interface altogether or reworking it completely for go-imap v2. I don't remember us arriving at some consensus regarding this though.
It will break API with some extensions so some careful judgement is needed to figure out what we can merge into v1. Some breakage may be acceptable, for example merging https://github.com/foxcpp/go-imap-namespace is probably okay - it will prevent backends from advertising custom namespaces but I do not expect this to be used often and it is unlikely to cause any real breakage e.g. for clients. |
Even after merging emersion/go-imap-compress#6, COMPRESS doesn't work for me because the reader thread reads compressed data without the deflater in place which messes up the connection state completely. I found a workaround (see this and this. With these two additional changes, COMPRESS seems to actually work for me :) Does it make sense to try to get them merged? I feel like #342 might also address this race condition issue. In any case, please include the raw-string fix from emersion/go-imap-compress#6. |
OK, so for v1, you think it's best to ignore |
@CrawX That's weird because e.g. STARTTLS works correctly... In any case it's unrelated to this PR, so please open a separate issue about it. |
2d90431
to
aad5f77
Compare
aad5f77
to
e5b9306
Compare
Merged UNSELECT and APPENDLIMIT. Not sure COMPRESS is worth the complexity… |
Superseded by #606 |
First round of changes for #322.
IDThis PR does not include server-side change to the UNSELECT command required by #341 (needs rebase after #341 gets merged)