4.x: register routing in weighted order of Server and HTTP Features #8826
Conversation
…stering non-HTTP Feature elements to the routing. With the updated version, all elements (filters, routes, services) are ordered depending on the feature's weight. This is achieved by creating a new HttpFeature for each Server Feature with the same weight, that collects all registrations and applies them once the HTTP Features are ordered by weight. HttpFeature registered from a Server Feature is left intact and applied on the real builder (as this already works as it should)
tomas-langer
requested review from
danielkec,
romain-grecourt,
spericas and
tjquinno
oracle-contributor-agreement
bot
added
the
OCA Verified
|
The coding changes look OK to me, although I do not know this area of the system. The user whose questions raised our awareness of this issue has specifically asked for public documentation explaining, first, the ordering of filters vs. handlers (maybe we think it should be intuitive but we can at least state what that ordering is) and, second, how weighting affects that ordering. Ideally such a doc update should be part of this PR...maybe a brief section on the webserver page in the request handling section? |
|
Tim, I was also asking about the ordering of filters vs filters from features. It seems like an undue burden to create a ServerFeature, and an HttpFeature, just so I can correctly weight my filter, don't you think? Seems like that would be buried too deep in uptake, and be subject to unnecessary brittleness for each new release... Sounds like a good argument for a "standard" feature where you can plug in your filter (with a weight, and a name maybe?). |
After this PR, you can either create an HttpFeature or a ServerFeature - depending on your use case. So the ordering is: Routing is "just" another HTTP feature that has default weight (except for the capability to register HttpFeatures), that is why you cannot register a filter outside of its scope. |
|
After a discussion with @RickyFrost, I still think we should require a feature to have filter/routing weighted. Otherwise we may end up with confusing behavior |
Added documentation for Context feature. Reorganized webserver.adoc, as some sections were within wrong chapters; updated TOC
|
Updated documentation of WebServer |
Co-authored-by: Daniel Kec <[email protected]>
…elidon-io#8826) * Correctly handle order of Server Features and HTTP Features when registering non-HTTP Feature elements to the routing. With the updated version, all elements (filters, routes, services) are ordered depending on the feature's weight. This is achieved by creating a new HttpFeature for each Server Feature with the same weight, that collects all registrations and applies them once the HTTP Features are ordered by weight. HttpFeature registered from a Server Feature is left intact and applied on the real builder (as this already works as it should) * Updated CORS weight to 850 to align with the documented (and intended) ordering * Added documentation for server features. * Added documentation for Context feature. * Reorganized webserver.adoc, as some sections were within wrong chapters; updated TOC * Added `HttpFeature` documentation. --------- Co-authored-by: Daniel Kec <[email protected]>
…8826) (#8840) * Correctly handle order of Server Features and HTTP Features when registering non-HTTP Feature elements to the routing. With the updated version, all elements (filters, routes, services) are ordered depending on the feature's weight. This is achieved by creating a new HttpFeature for each Server Feature with the same weight, that collects all registrations and applies them once the HTTP Features are ordered by weight. HttpFeature registered from a Server Feature is left intact and applied on the real builder (as this already works as it should) * Updated CORS weight to 850 to align with the documented (and intended) ordering * Added documentation for server features. * Added documentation for Context feature. * Reorganized webserver.adoc, as some sections were within wrong chapters; updated TOC * Added `HttpFeature` documentation. --------- Co-authored-by: Tomas Langer <[email protected]> Co-authored-by: Daniel Kec <[email protected]>
Resolves: #8816
Description
Correctly handle order of Server Features and HTTP Features when registering non-HTTP Feature elements to the routing.
With the updated version, all elements (filters, routes, services) are ordered depending on the feature's weight. This is achieved by creating a new HttpFeature for each Server Feature with the same weight, that collects all registrations and applies them once the HTTP Features are ordered by weight. HttpFeature registered from a Server Feature is left intact and applied on the real builder (as this already works as it should)
Documentation
This aligns with the internal documentation of feature weights.
I have added update of WebServer documentation in the latest commit.