Tickets :: Comment on [#14811] Attachments get lost after drag&drop import

* Your Email Address
* Spam protection	Enter the letters below: . ,. ..___ .. , \./ \| \|[__ \| \./ \| \|/\\|[___\__\| \|
Comment	> I have spent some time looking at this issue from different perspectives. > > Currently, I'm wondering if this bug may have been introduced by a > change in common browser behavior, and not by a code change in Horde. > > What I noticed is that the problem of missing attachments only shows > up when the upload of several files via drag-and-drop actually occurs > at once, i.e. it only happens when these file uploads take place in > parallel. The problem really manifests itself when the second upload > requests completes before the first one is finished (or the third one > before the second, etc.). So it's a matter of timing. I searched for > ways to prevent that from happening on the client side (using > Javascript), but that didn't prove successful, at least with my level > of Javascript knowledge and given the concurrent nature of Javascript > processing. So I ended up tackling this problem on the server side. > Recently, I built a special configuration on our load balancer that > will queue parallel Imp file uploads of the same session and only > allow one upload request to proceed at a time (the second upload > commences only after the first has finished), thereby serializing one > user's upload requests. After this modification to server-side upload > request timing, no more problems with drag-and-drop attachment > uploads have come up. > > So my theory is: Could it be that common browsers formerly would only > upload one file at a time in XML-Http-Request environments, but > nowadays, they upload several files in parallel, and Imp/Horde is not > prepared for this parallelized upload behavior? > > By the way, in case that others who are experiencing this trouble > haven't noticed yet: this problem does not occur when clicking the > "Add Attachment" link and selecting several files for upload in the > file selection window. When uploading several files at once this way, > only one HTTP upload request is generated which uploads several files > in a row, as opposed to the drag-and-drop method, which creates > several HTTP requests, and these, in turn, upload one file each. (One > can make a distinction between these types of file upload requests, > initiated either through drag-and-drop, or by clicking the link, on > the HTTP level by examining the query parameters. While the upload > URL is the same otherwise, the "one request but potentially many > files" type of request carries a "jsonhtml=1" parameter.) > > From the insights I have gathered so far, I reckon the easiest way to > permanently resolve the timing issue would be a modification on the > client (Javascript) side. If one could have some sort of > token/semaphore system to limit the number of upload request which > can happen at the same time, this would effectively serialize the > upload requests and thus resolve the issue of corrupted drag-and-drop > attachment uploads. So the idea would be: Initially, there is exactly > one "upload permission" token held by the main process. Each > Javascript file upload requests needs to acquire this "upload > permission" before doing anything. Once the first request takes this > token, it may start its upload process, exclusively. Meanwhile, a > second upload request could be waiting in the browser, but not > proceed, because there is no further upload permission token. So the > second upload will wait for the first one to finish, as the first > upload returns the upload permission token upon completion to the > main process, and the second uploads now seizes control of the token. > And so on, until all uploads are completed. But like I said, > unfortunately, I'm unable to implement such a mechanism in Javascript > myself. > > Another way that I could think of to resolve this would be to combine > the "several requests with one file each" into a single request that > uploads several files, like is done when clicking the "Add > Attachment" link. But I suppose that this kind of "request merging" > is not possible, because that's probably what would have been > implemented originally, would it be feasible. I think it's safe to > assume that the current versatile way of the "imp/addAttachment" > request is really there for a reason. i.e. because "request merging" > is not possible in Javascript.
Attachment
Watch this ticket

Saved Queries