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

Data serialization is broken if you are using full URL to API on your hostname #8852

Closed
stalkerg opened this issue Feb 2, 2023 · 7 comments · Fixed by #8876
Closed

Data serialization is broken if you are using full URL to API on your hostname #8852

stalkerg opened this issue Feb 2, 2023 · 7 comments · Fixed by #8876

Comments

@stalkerg
Copy link
Contributor

stalkerg commented Feb 2, 2023

Describe the bug

My API is on the same hostname but in sub path "/api". My fetch do things like fetch('https://my.site/api/get_user') .
The URL from this fetch is testing on the server side is here https://github.com/sveltejs/kit/blob/master/packages/kit/src/runtime/server/page/load_data.js#L190 and removing the hostname from the URL because the origin is the same, but the client trying to search the full path by selector because we use fetch URL as is here https://github.com/sveltejs/kit/blob/master/packages/kit/src/runtime/client/client.js#L603 .

It raises the second request to API, from CSR.

Reproduction

In the load function, you should make a fetch with the full path to the same hostname.

Logs

No response

System Info

System:
    OS: Linux 5.4 Ubuntu 20.04.5 LTS (Focal Fossa)
    CPU: (12) x64 AMD Ryzen 5 3600 6-Core Processor
    Memory: 37.92 GB / 62.81 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 18.12.1 - /usr/bin/node
    npm: 8.19.2 - /usr/bin/npm
  npmPackages:
    @sveltejs/adapter-node: 1.1.4 => 1.1.4 
    @sveltejs/kit: 1.3.9 => 1.3.9 
    @sveltejs/svelte-virtual-list: github:sveltejs/svelte-virtual-list => 3.0.1 
    svelte: 3.55.1 => 3.55.1 
    vite: ^4.0.4 => 4.0.4

Severity

serious, but I can work around it

Additional Information

No response

@stalkerg stalkerg changed the title Data serialization is broken if you are using full URL to API to your hostname Data serialization is broken if you are using full URL to API on your hostname Feb 2, 2023
@stalkerg
Copy link
Contributor Author

stalkerg commented Feb 2, 2023

SvelteKit is thinking of exclusive hostname usage, but it's definitely wrong.

@eltigerchino
Copy link
Member

My API is on the same hostname but in sub path "/api". My fetch do things like fetch('https://my.site/api/get_user') .

Can you confirm if your issue is similar to #8851 where using the SvelteKit provided fetch is unable to find APIs outside the framework on the same host?

If it is similar, it should be fixed by #8869

@stalkerg
Copy link
Contributor Author

stalkerg commented Feb 3, 2023

@s3812497 seems like I have no similar issue because I am using handleFetch, anyway I have no crash, in my case, just serialization is broken. I suppose is a different issue but on the same theme.

@eltigerchino
Copy link
Member

eltigerchino commented Feb 3, 2023

@s3812497 seems like I have no similar issue because I am using handleFetch, anyway I have no crash, in my case, just serialization is broken. I suppose is a different issue but on the same theme.

Do you mind uploading an example project that reproduces this issue and the actual / expected behaviour?
I'd like to investigate further.

@stalkerg
Copy link
Contributor Author

stalkerg commented Feb 3, 2023

I will try. Also, it seems like #8851 it's about server.js, but my issue is about fetch in load function of +page.js.
But again, you can look into my links and it will be clear - SSR uses only path for a tag with data, but on CSR a browser trying to find this tag by full URL with the hostname.

I am not sure how to fix it... basically, we can't remove the origin if it's not a part of SvelteKit routes.

PS I am found a workaround - just remove the origin (protocol+hostname) if it's the browser inside handleFetch.

dummdidumm added a commit that referenced this issue Feb 3, 2023
fixes #8852

Slices the origin from any client fetch request URLs so that they're always similar in format to fetches done on the server, which is important to find cached responses

---------

Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
@stalkerg
Copy link
Contributor Author

stalkerg commented Feb 3, 2023

@s3812497 @dummdidumm thanks!

@eltigerchino
Copy link
Member

@stalkerg thanks for filing the issue :)

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

Successfully merging a pull request may close this issue.

2 participants