8000 feat(http): Add `redirect` property to hook context by vonagam · Pull Request #2484 · feathersjs/feathers · GitHub
[go: up one dir, main page]

Skip to content

feat(http): Add redirect property to hook context#2484

Closed
vonagam wants to merge 1 commit intofeathersjs:dovefrom
vonagam:feat-redirect
Closed

feat(http): Add redirect property to hook context#2484
vonagam wants to merge 1 commit intofeathersjs:dovefrom
vonagam:feat-redirect

Conversation

@vonagam
Copy link
Member
@vonagam vonagam commented Oct 27, 2021

Adds standard way to specify a redirect location.

Before it was ok (not perfect, but ok) to do it with an express middleware but since there is now koa transport (and potentially in the future there will be other bare bone http one) it would be more beneficial to have a proper way for common functionality.

To do it consistently had to add encodeurl dependency to transport-commons - both koa and express use it to escape location, but koa does not have .location() function (unlike express), only .redirect() which also does bunch of other stuff with body.

If statusCode is not specified and redirect is present, then status defaults to 303. Default should be either that or 302 (former says to use GET request, later should be for temporary redirects with same request method).

Made code in rest between koa and express a little more consistent.

Also since a hook manager can theoretically (if overwritten) return a different context from one that was passed in to initializeContext have to set res.hook/ctx.hook twice - first when base is created (in case a method throws), second after a final context returned. (Not that anyone would do it, just a pedantic change.)

Still need to add some tests.

@vonagam vonagam force-pushed the feat-redirect branch 2 times, most recently from 2d14a00 to 4c657f4 Compare November 8, 2021 16:57
@daffl
Copy link
Member
daffl commented Nov 10, 2021

Thank you for putting that up! I'm a little torn of adding HTTP specific things (this could be done in a Koa middleware as well right?) into the hook context although granted this has already snuck in with the statusCode property. The question would be how this should behave with different transports (like websockets). With statusCode e.g. a websocket connection can just ignore it but I'm not sure what should happen if redirect is et.

@vonagam
Copy link
Member Author
vonagam commented Nov 10, 2021

Yeah, it could be implemented in a custom middleware. But if you create a library and don't know which transport end-user will have then you will need to implement a custom middleware for each http transport (before there was only one official, now there are two, in future there can be more). And there will be no standardization, meaning that if some other library or user himself want to work with redirects then it might lead to conflicts between solutions.

For me redirects seem like a really essential part of http protocol that it is strange to see no way to specify them in feathers.

With websocket redirect should be ignored just like statusCode. Ideally it might have made sense to move context.statusCode into context.http.status and context.redirect into context.http.redirect (and maybe add other http stuff, like ability to set response headers), but it would be a breaking change now and as i understand you want to keep migration as smooth as possible.

@daffl
Copy link
Member
daffl commented Nov 20, 2021

I was actually thinking exactly the same thing with context.http when reading your comment. I think we can still make the statusCode part backwards compatible (e.g. const staus = context.statusCode || context.http.status || 200). Should we do that instead? Then it would be easy to add something like context.http.reponseHeaders as well.

@vonagam
Copy link
Member Author
vonagam commented Nov 21, 2021

To make statusCode backwards compatible I think it makes sense to implement it as getter/setter for http.status, so that end user don't have to do context.statusCode || context.http.status and avoid situations when values go out of sync with different hooks using different approaches. It is also possible to add a depreciation message in getter/setter about move to http.status and removal of root statusCode in the distant future.

@daffl
Copy link
Member
daffl commented Nov 26, 2021

#2496 has been merged so we probably want to update this one accordingly.

@vonagam
Copy link
Member Author
vonagam commented Nov 26, 2021

Oncehttp.responseHeaders was mentioned the need for redirect property vanished since a redirect is just a combination of a status and a header. Redirect functionality in feathers can be exposed (if there is interest in it) as some utility function.

So I rebased #2486 and after (if) it is merged responseHeaders can be introduced. Then this PR can be converted to an addition of a utility function or closed.

@vonagam
Copy link
Member Author
vonagam commented Apr 4, 2022

#2524 is merged and this redirect functionality should be supported now with setting context.http.location.

@vonagam vonagam closed this Apr 4, 2022
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 this pull request may close these issues.

2 participants

0