Taku Amano

@szmarczak Oh, and to be clear, the "modifying `getPath()`" we are talking about now refers to the following changes. We want to implement this change in a less performance-degrading way....

@szmarczak Thank you! I think I understand your thoughts. It will be helpful. I consider the following ### What are the responsibilities of Hono routers? The `match()` method of Hono's...

@szmarczak Thanks. I understand that there are other opinions, but I still think that `getPath()` should be modified.

I would like to refer to #2688 for discussion. If anyone has an opinion, please comment. ### Expected Routing Results Is this the expected routing result? https://github.com/honojs/hono/pull/2688/files#diff-8ac13809c9886e994d1db33943de82df4d6c5d88b73fd0270c0189804ff565c2R736-R775 There may be...

@szmarczak Thanks for the comment! > (nor %3F otherwise it will mistake it for a query). If you read the code, you will see that we extract the path component...

@szmarczak Sorry, you were right from the beginning on the following points you mentioned and my understanding was wrong. If we look at it in terms of "segments", I think...

@fzn0x Thanks for the suggestion! First of all, I don't think the cache will speed up the process, since we won't be calling getPath() multiple times for the same request...

FYI The results of using symbols and multibyte characters in the routing definitions were investigated in the major frameworks. They vary considerably from framework to framework. I don't think "we...

If what we need is a result similar to Ruby on Rails, then the following changes will accomplish this. (Actually, it's a bit more complicated, but it's "encode when adding...

If the expected behavior is equivalent to Ruby on Rails, I think #2711 can achieve this. I feel this is better than https://github.com/honojs/hono/pull/2688 because it is less burdensome at the...