The served multiplexer now allows you to override a specific handler
pattern. Previous behaviour was to simply append the new matching
handler onto the end of the handler stack, and therefore it would never
be called since any match would already be dispatched to the first
definition.
The new behaviour is that any handler definition whose pattern matches
an existing handler will remove the previous handler from the stack
before being appended to the end.
This means for resolving the order of precendence of an overriding
handler you simply follow the sames rules as if the original overriden
handler had never existed, rather than assuming that the new handler
takes the position of the original.
For example, given the following handler definitions:
handle("/foo").get(foo);
handle("/" ).get(bar);
handle("/foo").get(baz); // Overrides the previous by removing it
And the following request:
GET /foo HTTP/1.1
The handler 'bar' is called since it matches and comes before the
new '/foo' handler.
The served multiplexer now allows you to override a specific handler pattern. Previous behaviour was to simply append the new matching handler onto the end of the handler stack, and therefore it would never be called since any match would already be dispatched to the first definition.
The new behaviour is that any handler definition whose pattern matches an existing handler will remove the previous handler from the stack before being appended to the end.
This means for resolving the order of precendence of an overriding handler you simply follow the sames rules as if the original overriden handler had never existed, rather than assuming that the new handler takes the position of the original.
For example, given the following handler definitions:
handle("/foo").get(foo); handle("/" ).get(bar); handle("/foo").get(baz); // Overrides the previous by removing it
And the following request:
GET /foo HTTP/1.1
The handler 'bar' is called since it matches and comes before the new '/foo' handler.