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.
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.