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

* Your Email Address
* Spam protection	Enter the letters below: .__ .__.. .._. . [__)[__]\|_/ \| \| \| \| \|\| \_\|_\__\|
Comment	>> 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 ? >
Attachment
Watch this ticket

Saved Queries