[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         | ryu at ryux.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
------------------------------------------------------------------------------


ryu at ryux.org (2013-08-14 17:07) wrote:

> This doesn't make sense to me, and sounds like a client issue:

Yes, you're problably right. It's maybe a client issue. I think too.

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

If I'm not wrong, in EAS 12.1, the GetAttachment command write only  
the attachment in the stream. It doesn't add any wbxml or else around.  
I think the problem is near this point.
In EAS 14.1, the data stream comes around tag and others informations...
Maybe in case or raw data, the client does not detect the flush...

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

Ok, it is here than I see a strange information I need to dig. In my  
dump of the bad file, we can see that the content-type is not a EAS.
Transfer-Encoding: chunked
Content-Type: text/html

Maybe the headers are not sent when the php buffer is flushed and it  
is the default content type which is sent... I have to check this  
point. Maybe can you say more.

>
>> 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.
With more tests, I can say it was my carreer which was too slow and  
not stable. Now, I've retrieved some bigger files 3.5MB and all 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.

Ok for the activation of the buffer. I don't remove it in my test, I  
just remove the limit of the size.
I agree with this protection, but if my tests are valid, I think this  
value should be a parameter with a higher default size (10MB ?) (My  
Mail server accepts until 64MB...)

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

All my users have an iPhone or an iPad. WIth many ios version. Mine is  
an old 4.2.1. But the problem exists with newest.

Have you test this issue with an Apple device ?