Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workaround for missing previews of large PDF and Office files #3089

Closed
erikfdev opened this issue Jul 28, 2023 · 4 comments · Fixed by #3298
Closed

Workaround for missing previews of large PDF and Office files #3089

erikfdev opened this issue Jul 28, 2023 · 4 comments · Fixed by #3298

Comments

@erikfdev
Copy link

Actually this is a request to implement a workaround for the fact that CODE (at least version 23.05.2.2) does not always reply '100 Continue' on POST /cool/convert-to/png requests containing the 'Expect: 100-Continue' header.

This header is inserted by Guzzle when the file to be converted is larger that some given size (1MB I believe). Guzzle then awaits a '100 Continue' reply before sending the contents of the document.
When CODE does not reply this 100 Continue, the apache process running richdocuments hangs, waiting 2 minutes before giving up. Obviously no preview is then generated.

The workaround consists of forbidding Guzzle to insert the Expect header.
This can be done by means of a one line change in lib/Preview/Office.php, function getThumbnail().
Insert after the line containing $options['multipart'] = ...
following line:
$options['expect']=false;

@erikfdev
Copy link
Author

I reported the real CODE issue here:
CollaboraOnline/online#6983

@erikfdev erikfdev changed the title Workarund for missing previews of large PDF and Office files Workaround for missing previews of large PDF and Office files Jul 28, 2023
@joshtrichards
Copy link
Member

Upon reading this my gut reaction was "well, let's get this fixed in CO" (rather than implement a workaround), but in doing initial research it seems that there may be no requirement to wait indefinitely for a response
anyhow. Apparently cURL defaults to waiting only one second... then it sends the body along.

The initial digging into Expect: 100-Continue left me wondering whether it may be one of those "useful ideas but not well enough supported and just obscure enough to be more likely to bump up against buggy code paths" areas of HTTP.

There also may be some differences with how Nginx handles things (versus Apache) when used as a proxy - and that's certainly something we have to weigh in terms of compatibility - but further digging is necessary to confirm that better (so take with a grain of salt).

The thing that makes me hesitant is: why Guzzle doesn't already do the 1s send the body anyway approach - after all it's (traditionally) cURL-centric.

If the behavior really is as you describe (I'm on my phone so I don't have good access to my lab at the moment), this would seem a worthwhile bug to address sooner rather than later.

Leaving hanging http processes around unnecessarily + random broken previews (with no clear reason from the user experience side of things) is not good.

@juliushaertl
Copy link
Member

Makes sense, let's add that option as a workaround. I'll subscribe to the Collabora issue was well to get rid once merged and released upstream.

Pushed a PR to #3298

@erikfdev
Copy link
Author

Apparently the problem does not occur anymore with Nectcoud 27.1.3 and CODE 23.05.5.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants