Way to differentiate a progressively enhanced form submit.
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 20.8k
- Forks
- 2.3k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 156
Description
Describe the problem
Consider the following scenario.
- User submits a login form.
- Server validates the request.
- Server responds with a 302 redirect response, with a Set-Cookie header.
If SameSite=strict is set in the Set-Cookie header, it would
- work in a progressively enhanced form submit
- might not work in a non-enhanced, no-JS form submit
This is because step 3 does not work in some recent versions of Firefox and Chrome.
We could see the Cookie from the browser storage inspect tab, but not in the request immediately following the 302 response.
Progressively enhanced form works, because the Fetch request responds with 200 OK.
Describe the proposed solution
An alternative to RequestEvent.isDataRequest such as isEnhancedFormRequest.
isDataRequest:boolean;
trueif the request comes from the client asking for+page/layout.server.jsdata.
Alternatives considered
Considered workarounds using the following request headers:
x-sveltekit-action: not included in non-enhanced submit.content-type: ismultipart/form-data;in enhanced submit.
Importance
would make my life easier
Additional Information
In a non-enhanced form submit, the following HTML header can be returned for client-side redirect without JavaScript. Throwing redirect with an option for client-side redirect can help with this issue (if the server is returning a SSR HTML).
<head><meta http-equiv="refresh" content="0; url='REDIRECT_URL'"></head>
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the RequestEvent.isDataRequest entry in the public types documentation and the issue's examples of x-sveltekit-action and content-type. Trace how enhanced and non-enhanced form requests are currently distinguished. Done means providing a reliable way for server code to identify enhanced form submissions without relying on headers that differ incidentally.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend, web-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100