Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Url encoding in routes #15

Open
djeka07 opened this issue Aug 21, 2018 · 2 comments
Open

Url encoding in routes #15

djeka07 opened this issue Aug 21, 2018 · 2 comments

Comments

@djeka07
Copy link
Contributor

djeka07 commented Aug 21, 2018

I´m noticing a difference between setting up the ApiStub and what is actually being matched.
The stubbed route needs to be without url encoding.

Example:

This is the request that is being called to the Stubbery Api:
http://localhost:9000/api/hello/%23world%23

To get a match I need to set up the stubbed route as:

return _apiStub.Request(HttpMethod.Get)
    .IfRoute($"/api/hello/#world#")
    .Response((req, args) =>
    {
        return responseBody;
    });

This was hard to find and needed debugging for being able to understand what was happened.
I would like to be able to set up the stub exactly as the request with url encoding.

Please let me know if I can help in any way.

//André

@markvincze
Copy link
Owner

Hi @djeka07,

Thanks for creating this issue, nice catch!

I'll try to find some time this week to think this through and decide what would be the proper solution, either change the behavior, or just add documentation, and will issue a fix.

@markvincze
Copy link
Owner

Hey @djeka07,

Sorry for the late response.
I've spent quite some time on this last weekend, but I'm still having a hard time wrapping my head around this issue and what the proper solution would be. It seems that all layers have various assumptions about how to handle hashmarks, and are doing something custom. HttpClient seems to encode it automatically, while Postman and the REST Client extension I'm using in VSCode seems to just omit it altogether. Probably this is related to the fact that according to the standard, anchors are only for the client-side browser to interpret, and are not intended to be used by the server.
Can you share a bit more about the scenario you need this for?

(I also did the same test with an at (@) sign, which seems to be behaving yet again differently, which makes the problem even trickier.)

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

No branches or pull requests

2 participants