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

* Your Email Address
* Spam protection	Enter the letters below: .__..__ . ..__ \| \|[__)\| \|[__) \|__\|\| \\|___\__\|\| \
Comment	> Ok, good news for you ;) > I finish new tests and all is clear for me, I think > > This time, i was afraid than the content type was not sent because of > the ouput buffer. And it was the case. > > You returns the Content-Type at the end of the method _handle() > (because you don't know if it is multipart or no) in > ActiveSync_Request_ItemOperations.php. > And so, in case of bigger files which are greater than 1MB, the fluh > send the first part of the stream withtout the valuable header... > > I add a new dump from the GetAttachment command. In this case, the > content-type is image/jpeg. And all is good. > > Then, I removed my previous patch with the output buffer size and > forced the header to Content-Type: application/vnd.ms-sync.wbxml > before to read the stream. > All was ok. > You're right with the buffer. Not needed to change it. > > So, the questions are : > > 1. Why the content-type is sent with a bad value (text/html, see the > dump). My feeling is the Apache server which autodetects and adds a > type. (And fails with the binary of the wbxml and add text/html, but > success with the GetAttachment command). > > 2. Why the client makes a new call and breaks the connection after > retrieving the first part (1MB) of the file. Maybe it checks the > format, does not detect a valid HTML format and retry one more time. > > I think I correctly sum up the problem. > > I'm going to check if I can remove default Content-Type in apache. > > What do you think about this deeper investigation ?
Attachment
Watch this ticket

Saved Queries