Tickets :: Comment on [#12970] Don't override sticky OPTIONS values with default values.

* Your Email Address
* Spam protection	Enter the letters below: . .. .. .. .. . \| \|\|__\|\| \|\| \|\|\/\| \|__\|\| \|\|__\|\|/\\|\| \|
Comment	>> What do you mean "with mimesupport set at 1 or 2"? This is not a >> configurable value. It comes from the client and it indicates what >> the client is able to understand, or what it is expecting to be >> returned. Changing it on the server side after the client sends it >> leads to undefined behavior because the device is not longer >> receiving what it is expecting in return. >> > > I set it manually to see what the client would say. Based on my > comment #32, the client supports type 1. It's defined at provisioning > time or when adding a collection. > I've verified that the client never sets it in itemoperations for > unencrypted messages and I think it's normal, as it's an optional > element, unless the client is fetching a S/MIME message. For an > encrypted message, there is no itemoperations command being sent when > receiving the message > >> Wait, I'm confused now. You said earlier that the MessageClass was >> always being set to IPM.Note, and NOT IPM.Note.SMIME. Below, it >> clearly shows that it IS set correctly. > > That's when I manually enable a mimetype. I did it to check what > would happen later on in the chain if given the mimetype I think it > expects. > >> This means that the client is NOT requesting the MIME data. You will >> never get the full MIME message as long as the client is sending >> MIMESUPPORT of 0. > > The client is not sending mimesupport of 0. Horde is using the > default value because it could not find it in the request, but a > value of 1 has been sent when adding the collection via a sync > command and I think that it's the value which should be used since > the client is not sending an updated value of 0 per example. > > >
Attachment
Watch this ticket

Saved Queries