feat: allow http calls without origin header #1941
Conversation
Example Clerk auth provider does not work when both Authorization and Origin headers are set. This allows one to skip setting the origin header explicitly.
amrbashir
left a comment
amrbashir
left a comment
There was a problem hiding this comment.
Thank you, Could you also add a change file in .changes directory?
| // In case empty origin is passed, remove it. Some services do not like Origin header | ||
| // so this way we can remove it in explicit way. The default behaviour is still to set it | ||
| if cfg!(feature = "unsafe-headers") | ||
| && headers.get(header::ORIGIN) == Some(&HeaderValue::from_static("")) |
There was a problem hiding this comment.
I don't think we should match on an empty string, because there might be some users who want to send empty string for Origin. I'd rather add a new option when making the request, for example:
fetch(url, {
sendOriginHeader: false
});There was a problem hiding this comment.
This is something I was thinking a lot. Like I'd like to avoid adding extra parameters to the fetch and try to keep the fetch as close to global fetch. And in case of patching global fetch with tauri-http (example to get control what fetches actually can be made) the consumers assume standard fetch. Different libraries support some pre/post hooks for different operations that allow example inject headers and such like for custom auth and they operate with the RequestInit object.
And the syntax of Origin header is:
Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>
Sending an empty string is invalid format. In case user wants to hide the origin for example privacy reasons they should set it to null string literal.
For these reasons I ended up with sending empty string in the origin header as the mechanism.
I hope my reasoning makes sense.
There was a problem hiding this comment.
I was comparing with how node and deno runtimes behave and both allow setting Origin to an empty string. However your reasoning is quite valid and I think we should go with your approach until someone else asks for this specific behavior.
Package Changes Through 943de57There are 8 changes which include dialog with patch, dialog-js with patch, positioner with patch, positioner-js with patch, http with patch, http-js with patch, shell with patch, shell-js with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
Co-authored-by: Amr Bashir <[email protected]>
amrbashir
changed the title
|
Thank you |
Currently the request to Ollama contains `Origin: null` header, which is not accepted by Ollama server (server responds with 403). There seem to be a way to remove Origin header, by setting it's value to an empty string. fixes: - gitbutlerapp#8078 - gitbutlerapp#5862 ref: - tauri-apps/plugins-workspace#1941 - https://github.com/ollama/ollama-js/blob/6a4bfe3ab033f611639dfe4249bdd6b9b19c7256/src/browser.ts#L38 - https://github.com/gitbutlerapp/gitbutler/blob/9af0e4bbaa845aeb40a82f22ad66975a61990654/Cargo.lock#L8431
2 participants
Example Clerk auth provider does not work when both Authorization and Origin headers are set. This allows one to skip setting the origin header explicitly.
In my application I'm routing all requests via tauri-http by patching global fetch. And I'm using custom Clerk setup to get the token shared between js and rust. To do that I need to use Authorization header instead of cookies to communicate with Clerk. And Clerk fails if there is both Authorization header and Origin header, as such I need a way to send requests without origin header.
I do like the default behavior of setting the origin header if it's not set as that mimics the browser behavior. But I also need a way to not send it. This does not change any existing behaviors, and Origin header can anyways be:
So empty string would be invalid header value according to the spec. As such I was thinking that if client has sent empty origin header we could just omit the origin header.