Double slash at the end of base path of url

Google Cloud Apigee
1

How to handle double slash at the end of base path of url?

Lets say I have proxy setup having base path as below:

https://myorg.apigee.net/subpath

which handles all the conditional flow hitting above url.

Then I have proxy with base path as below to handle invalid resource url:

https://myorg.apigee.net/

But, if I hit below url,

https://myorg.apigee.net//

It gives:

{"fault": {"faultstring": "Invalid path GET // HTTP/1.1","detail": {"errorcode": "protocol.http.InvalidPath"}}}

How to handle this invalid double slash and return customize error message.

Thanks,

2

Hi, I just tried this and am not seeing that behavior.

When I set up a proxy endpoint with basepath of /

and then invoke it with

GET http://myorg.apigee.net/

I get the same result as when I invoke it with

GET http://myorg.apigee.net//

The proxy is a loopback, and so In both cases I am getting a 200 with no payload in response. This is as expected. I am using curl, so it is possible the double-slashes in the URL are being collapsed. (Not sure)

Can you provide more details please? Exactly what is the basepath you are using? you wrote “hen I have proxy with base path as below” but you didn’t specify anything “below”. Exactly how are you invoking this proxy? With which tool? Show code.

3

@Dino

I have a proxy setup, which is supposed to handle all invalid url request with respect to basepath.

ProxyName: InvalidUrl

Url: https://myorg.apigee.net/

Base Path: /

There is no target end points.

I have following in my preflow, so whatever request comes to this proxy is basically wrong, so raise error.

<PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>Error.NoTarget</Name>
            </Step>
            <Step>
                <Name>RaiseFault.Error</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Error.NoTarget is javascript policy to setup error message:

context.setVariable("flow.error.status", "404");
context.setVariable("flow.error.message", "Resource not found: " + context.getVariable("proxy.pathsuffix"));
context.setVariable("flow.error.title", "Resource not found.");

and RaiseFault.Error is raise fault policy to raise above error.

So, If I hit,

https://myorg.apigee.net/

or https://myorg.apigee.net/doesnotexist

I see the trace of those requests within this proxy and it returns expected customized error message.

If I hit,

https://myorg.apigee.net//

there is no trace, that means, something happens within apigee, even before it reaches to proxy.

I have tried through curl, postman, and browser(chrome, firefox), same result.

{"fault":{"faultstring":"Invalid path GET \/\/ HTTP\/1.1","detail":{"errorcode":"protocol.http.InvalidPath"}}}

Thanks

4

ok, very clear. I understand now.

Next question - is this error not acceptable? It seems like a bogus path. Carefully designed URL patterns do not require multiple consecutive slashes. Nobody who wants to help developers would purposefully design an API like that; I don’t think so anyway.

Said another way: does the error that you see in the case of hitting the org+env with a path of // , present an obstacle or problem for you? Can you not simply coach your clients to NOT send such requests? (And doesn’t the error that gets sent back already do that, explicitly?)

You and I could spend time diagnosing this edge case, and maybe even raising a bug in Apigee Edge so that it would pass through the double-slash path to the API proxy. And that effort might possibly be valuable. But it seems more likely to be one of those situations like this:

Patient: “Hey Doctor, it hurts when I do THIS.”

Doctor: “Don’t do that.”

You tell me.

5

@dino

There is something called consistency and we want to be consistent with our error message. And there are QAs, who spent 80% time testing negative scenario than happy scenario :slight_smile:

same result

Thanks

1 Like
6

OK, I shall raise a bug on your behalf so that Apigee can correctly handle the case where URLs contain double slashes. I cannot commit to a fix timeframe for that scenario, though!

By the way, I have reproduced the exact behavior you described.

The ticket number is APIRT-3703.

If you have access to Apigee support, you can raise a ticket with the support desk to track the progress of this defect. They will attach the defect to your support ticket, and you’ll be notified when the defect is fixed.

7

@Dino Could you please let me know if this ticket is resolved? I donot have access to Apigee support

8

I’m sorry to report, this bug is still in the backlog!

9

@Dino Any idea by when this could be solved?

10

unfortunately, I don’t know when this will get solved. It seems to be a relatively simple case, but I don’t know how to engineering team will prioritize it. If you are a paying customer, I suggest that you raise a ticket with the Apigee support desk (through the support portal) to track the progress of this defect, and request that they raise the priority. They will attach the existing defect to your support ticket, and you can request an escalation. There’s no guarantee that an escalation request will result in an acceleration of fixing the problem, but if you’re a paying customer, there’s a better chance.