You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm able to attach a PDF file and add a link to it in my note, but it's difficult to access the file.
Clicking the link in my note (/api/notes/xxx/assets/xxx) produces a 200 response with Content-Type: text/html and renders a blank page.
Refreshing the page in Firefox and Chrome will continue to produce the same text/html response. A hard-refresh will bypass the browser cache and produce the appropriate Content-Type: application/pdf response. Accessing the attachment via curl also returns the correct Content-Type header.
Once the PDF is finally rendered in-browser (after hard-refresh), the browser's back button becomes non-functional and only adjusts the URL in the browser's URL bar but does not navigate away from the PDF.
This seems to be an issue with how the client-side code in the front-end web app renders responses returned by the backend server.
Expected Behavior
Accessing file attachments while navigating from the web app should produce proper Content-Type header responses.
Steps To Reproduce
Create a note.
Upload a PDF attachment for that note.
Include a link to the attachment with relative path [file][/api/...] or absolute path [file][https://domain.com/api/...]
Click the link.
Environment
Docker AIO through nginx reverse proxy
Docker AIO direct access
Extra Context
Cool project, thanks for building this.
I'm trying to deploy this for friends/family but the workarounds are not practical for non-technical users.
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Is This A Security Issue?
Describe The Problem
I'm able to attach a PDF file and add a link to it in my note, but it's difficult to access the file.
Clicking the link in my note (
/api/notes/xxx/assets/xxx
) produces a 200 response withContent-Type: text/html
and renders a blank page.Refreshing the page in Firefox and Chrome will continue to produce the same
text/html
response. A hard-refresh will bypass the browser cache and produce the appropriateContent-Type: application/pdf
response. Accessing the attachment via curl also returns the correctContent-Type
header.Once the PDF is finally rendered in-browser (after hard-refresh), the browser's back button becomes non-functional and only adjusts the URL in the browser's URL bar but does not navigate away from the PDF.
This seems to be an issue with how the client-side code in the front-end web app renders responses returned by the backend server.
Expected Behavior
Accessing file attachments while navigating from the web app should produce proper Content-Type header responses.
Steps To Reproduce
Environment
Extra Context
Cool project, thanks for building this.
I'm trying to deploy this for friends/family but the workarounds are not practical for non-technical users.
The text was updated successfully, but these errors were encountered: