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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12486
------------------------------------------------------------------------------
  Ticket             | 12486
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Can't download attachments over ActiveSync
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-14 15:25) wrote:

>> ... 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?