Started migrating routing configuration to the new configuration API #2186
Started migrating routing configuration to the new configuration API #2186
Conversation
what would you get for option 3? 405 response? |
bbe12a6
to
93ea41d
Compare
@jchannon that would depend on this https://github.com/NancyFx/Nancy/pull/2186/files#diff-85f32a7553a78a9ff4b2905f7c21280cR30 |
IMO this check should be done before it ever gets to the Module... I vote 3. |
I'd prefer option 2, feels like something that would benefit from being on the context anyway. |
@grumpydev I kind of thing 2 & 3 would be the way. I think throwing the exception is stupid. It means you can't temporarily toggle that feature on/off without making modification (even if that only means commenting out code) or it will throw exception at startup. I would vote 3 for this PR and then we create a new issue for 2 ? |
Only problem with removing the exception is that people could then add HEAD routes and they just wouldn't work with no indication as to why. I agree the exception should go, but I guess only when we fix the routing so it will give custom HEAD routes precedence over the default stuff, although I'm not sure why we don't already do that as that seems the "correct" thing to do. |
@grumpydev I'm trying to limit the scope so we can ship 2.0, not expand it.. unless you're offering to get a PR in for that behaviour? :D |
I'm just saying don't remove the exception yet until we've fixed it properly, so stick it in the context and log an issue to remove the exception/improve routing later :) |
@grumpydev you're just trying to avoid doing any work! ;) |
Avoid, no, postpone, yes :p |
Can someone explain to me why it belongs in the module or context when this AFAIK dictates if routing should occur? |
We are talking about the nancy environment object (and hence config in general) not this particular setting @phillip-haydon |
The setting itself should go away, but not yet. |
In that case option 2 and remove that setting when we can because it makes no sense |
No longer WIP. Updated description. Ready to be reviewed and pulled ping @NancyFx/most-valued-minions @NancyFx/nancy-core-contributors |
👍 Looks much cleaner than the old statics everywhere. |
Added one more thing to the description (Step 5) |
…ting Started migrating routing configuration to the new configuration API
Moved routing configurations over to the new configuration as part of #2000
RouteConfiguration
,RouteConfigurationExtensions
andDefaultRouteConfigurationProvider
EnableHeadRouting
toExplicitHeadRouting
when it was movedStaticConfiguration
HEAD
routing configuration check inNancyModule.Head
(see discussion below)INancyEnvironment
ontoNancyContext
Old description
Currently what's left is to figure out the best approach to get the
INancyEnvironment
intoNancyModule
because it is currently used by the Head declaration to throw an exception if you try to declareHEAD
route while it's disabledI think our options are one of the following
INancyModule
(feels icky)NancyContext
(feels less icky, and makes it accessible wherever the context is)NancyModule
I think option 3 is the most compelling because the DefaultRouteResolve also makes use of the setting to determine if it should translate
HEAD
requests intoGET
requests. Removing the check & exception would only mean that you'd not get an exception (which is a bit weird anyway) if you try to declareHEAD
requests while it's disabled.. it will just mean they'll never been able to be called until you toggle the setting