-
Notifications
You must be signed in to change notification settings - Fork 63
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
JAMES-2997 Extraction of charset cary over in Attachment content type #3316
Conversation
...s/jmap-draft/src/test/java/org/apache/james/jmap/draft/methods/MIMEMessageConverterTest.java
Outdated
Show resolved
Hide resolved
I don's see where you read this. This section of the RFC is linked to RFC 6838, which has a chapter about encoding (4.8). Let's suppose you upload a text file with content type text, charset iso-8859-1, and then you download it with content type text, charset utf-8. What is supposed to happen? Now I'm a bit worry about the merge of #3061 ... Anyway if you cannot set a different download charset, you should at least be returned the charset that was use for uploading, else your interpretation of the file can vary... |
The merge don't change anything. It don't affect stored things. It just removed a lye (where SetMessages returns the attachment contentType intended to be used, and not the actual one). |
Actually we should be thankful: removing the lie allow us to see that issue :-) |
Then if charset option is valid in content-type field, let's merge this. |
Ok, it's clear to me that charset is part of the RFC definition of media type,n and that this change is legitimate. |
can you retrieve the comments I made on the other PR? |
can you retrieve the comments I made on the other PR?
|
We can preserve all if you prefer. |
Previous implementations where not preserving charset upon: - composing a message via JMAP - storing an attachment related to a mailbox Note that JMAP attachment upload was preserving charset. **master** is also affected by this issue but the problem was hidden as SetMessages was returning the expected attachment metadata and not the actual one.
08ce2ca
to
cf30ce4
Compare
What does it mean? |
I miss context for explaining the quote. A ctrl+f on it did not highlight anything. |
mailbox/store/src/main/java/org/apache/james/mailbox/store/mail/model/impl/MessageParser.java
Outdated
Show resolved
Hide resolved
mailbox/store/src/main/java/org/apache/james/mailbox/store/mail/model/impl/MessageParser.java
Outdated
Show resolved
Hide resolved
.body(createdPath + ".attachments", hasSize(2)) | ||
.extract().asString(); | ||
|
||
assertThatJson(json) |
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.
can't we just assert the few paths we want to check rather than setting so many parameters to exclude things?
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.
I don't know how to do that.
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.
jsonpath + individual assertions
...mon/src/test/java/org/apache/james/jmap/draft/methods/integration/SetMessagesMethodTest.java
Outdated
Show resolved
Hide resolved
That's not a question of preference. That's a question of rightness. We are implementing protocols, what is the right solution? Personally I don't know, that's why I ask. |
|
|
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.
it looks ok (there's only the complex assertion that I would like to be fixed)
I had a look. I don't see easy wins |
test this please |
Merged |
RFC notes on this work: https://jmap.io/spec-core.html#uploading-binary-data Defines type as :
(hence my initial mis-understanding) https://tools.ietf.org/html/rfc6838 only defined registration procedures and is thus of little help. https://tools.ietf.org/html/rfc2045#section-5 helps
Espacially the last part:
Thus the JMAP quote above means "use the full header" |
To retrace the issue:
#3061 (comment)
#3061 (comment)
This logic leads to the code presented here.
#3061 (comment)
#3061 (comment)
Here is the separate pull request ;-)
My position is: