Add fetch wrappers, ignore network errors in actions view #26985
Conversation
GiteaBot
added
the
lgtm/need 2
silverwind
added
type/refactoring
|
I rewrote these fetches to be parallel, so the actions page will also load like 60ms+ faster now: 
|
github-actions
bot
added
the
type/docs
| contentType = 'multipart/form-data'; | ||
| body = data; | ||
| } else if (data instanceof URLSearchParams) { | ||
| contentType = 'application/x-www-form-urlencoded'; |
There was a problem hiding this comment.
multipart/form-data could be always the correct content type (well, without a file, application/x-www-form-urlencoded might be simpler)
While I do not see why it should support URLSearchParams, the URLSearchParams should mainly used for URL query string, but not a POST request.
(not blocker)
There was a problem hiding this comment.
Does the backend actually support both encodings interchangbly? Normal form behaviour is application/x-www-form-urlencoded for forms not containing a file, and I think the cleanest way for these is to encode them as URLSearchParams which ensures escaping is correct etc:
GiteaBot
added
lgtm/need 1
GiteaBot
added
lgtm/done
lunny
added
the
reviewed/wait-merge
GiteaBot
removed
the
reviewed/wait-merge
* upstream/main: Add more package registry paths to the labeler (go-gitea#27032) Extract auth middleware from service (go-gitea#27028) S3: log human readable error on connection failure (go-gitea#26856) [skip ci] Updated translations via Crowdin Fix "delete" modal dialog for issue/PR (go-gitea#27015) Fix context cache bug & enable context cache for dashabord commits' authors (go-gitea#26991) fix: typo (go-gitea#27009) Use secure cookie for HTTPS sites (go-gitea#26999) Add fetch wrappers, ignore network errors in actions view (go-gitea#26985)
| ### Fetching data | ||
|
|
||
| To fetch data, use the wrapper functions `GET`, `POST` etc. from `modules/fetch.js`. They | ||
| accept a `data` option for the content, will automatically set CSFR token and return a |
|
|
||
| return fetch(url, { | ||
| headers: { | ||
| 'x-csrf-token': csrfToken, |
There was a problem hiding this comment.
Are headers case-insensitive?
I've only seen them be called X-Csrf-Token yet…
There was a problem hiding this comment.
Yes, HTTP headers by definition are to be treated case-insensitive while reading them and in fact we should lowercase them all everywhere.
In HTTP2 the common headers are transferred via a mapping table that outputs lowercase: https://datatracker.ietf.org/doc/html/rfc7541#appendix-A
5 participants
fetchwrapper functions that automatically sets csfr token, content-type and use it inRepoActionView.vue.RepoActionView.vuewhere a fetch network error is shortly visible during page reload sometimes. It can be reproduced by F5-in in quick succession on the actions view page and was also producing a red error box on the page.Once approved, we can replace all current
fetchuses in UI with this in another PR.