Tickets :: Comment on [#12486] Can't download attachments over ActiveSync

* Your Email Address
* Spam protection	Enter the letters below: \ /.__.. ,.__..___. >< \| \| \./ \| \| \| / \\|__\ \| \|__\| \|
Comment	>>> ... if you are comfortable in PHP, you could also try investigating >>> the use of fseek() and ftell() in >>> Horde_ActiveSync_Request_ItemOperations::_getDataSize(), as that is >>> really the only difference in what happens to the stream between 12.1 >>> and 14.x requests. >> >> Ok, I finally found ! >> After 2 days of remote debugging on my test environment (with vim :) >> ), I solved this bug. >> >> As the ActiveSync message exceeds the size of the output buffer >> defined in the method getReponse of the class Horde_Rpc_ActiveSync >> (1MB), the transfer is splited in the Horde_ActiveSync_Wbxml_Encoder, >> _outTermStr(). The client detects this as a problem and request again >> the server. > > This doesn't make sense to me, and sounds like a client issue: > > 1) Why does it work correctly with the same size data in EAS 12.1 > then? The buffer limit is present in ALL EAS requests. > > 2) If the buffer size is exceeded, PHP should flush the buffer to > the client, and continue processing - which includes sending the > remainder of the data when complete, this should not be seen as a > separate connection, or broken connection, or whatever the client is > seeing it as. > >> I removed the limit for tests and all files can be downloaded ! >> >> BUT, if you put this limit, it is not for nothing I think... > > Correct. > >> BUT, after some tests, all my images are corrupted. The end of the >> image is not retrieved or else... It is maybe my connection which is >> very bad on my mobile now and I must test again with the WiFi. > > Again, this does not make sense to me. Both the 12.1 and 14.x > requests use the same chunk size and send the same amount of data. > >> I tell you later if it is ok. >> >> I would like to know the goal of the output buffer limit plz... > > Without the buffer, the data would be sent in small chunks (as it is > output) without knowing how much total data is going to be sent. On > clients that have progress bars displayed during the sync, this > breaks things, so the data is "de-chunked" and sent along with the > content-length data. The limit is protection against keeping too much > data in memory at one time. > > I'm still wondering not only why this only happens with 14.x > requests, but also why I am not seeing this regardless of the size of > the attachments I have. What clients does this happen with? >
Attachment
Watch this ticket

Saved Queries