3.1.0 --> 3.1.1 changes namespace behavior with leading slashes

[mydea]

After upgrading from 3.1.0 to 3.1.1, our app broke. I guess it is due to this commit:

3a25d71

Basically, our namespace was api/v2, and our rootUrl is /app, and our host is https://our-server.com.
Meaning our app runs on https://our-server.com/app/, and the ajax service is configured like this:

// app/services/ajax.js
import AjaxService from 'ember-ajax/services/ajax';

export default AjaxService.extend({
  namespace: 'api/v2',
  host: 'https://our-server.com'
});

Previously, it would correctly build the urls like this: https://our-server.com/api/v2/xxxx. After the upgrade, it would suddenly be https://our-server.com/app/api/v2/xxx.

We could fix it by changing the namespace to /api/v2, but I guess this kind of breaking change should not happen in a patch-level release.

[artzte]

We aren't using namespaces and were also broken by this patch. Easy enough to fix the inconsistency on our side, but yes, this was a breaking update.

[alexlafroscia]

@artzte can you describe the case that you are in, where this patch broke things for you?

[alexlafroscia]

@mydea I'm sorry about the breaking change here.

Can you step into the code and let me know how app is being added to the URL? Without it in host or namespace I'm unsure how that's ending up in the URL being used.

[artzte]

We had to add leading slashes to paths fetched using ember-ajax. We were not doing this consistently.

[Emrvb]

@alexlafroscia

Can you step into the code and let me know how app is being added to the URL? Without it in host or namespace I'm unsure how that's ending up in the URL being used.

Generally, urls without a leading slash are perceived as relative. Nothing is adding "app". That's just the path to the ember app.

In my opinion the mentioned commit should be reverted, unless the ember-data rest adapter changed its behavior as well. (I'm lagging a bit behind on ember-data versions)

[alexlafroscia]

Sure, I can revert that change and address the clean-up of the URL building in the next breaking change of this repo.

I'm not sure how to version that though -- is going back to the previous behavior also a breaking change?

[jherdman]

I think we need to support both right now, and clearly deprecate one or the other.

[alexlafroscia]

I've thought about this a bit and would these two potential plans:

• I cut 4.0.0 right now, from the current release. It's exactly the same as 3.1.1 (including this breaking change). Anyone that's already fixed the problem in their own codebase can upgrade and we're back to "stability"
  • The release notes will explain the situation and reference this conversation
• I cut 3.1.2 that reverts the change that caused this bug. Anyone that isn't on 3.1.1 yet would get that as their next version, "skipping" 3.1.1 that include the breaking change
• I deprecate 3.1.1 or otherwise mark, through NPM, that people should not install that version. I'll see if I can remove the version altogether, but I know that NPM doesn't really like that. A deprecation warning or something might be enough.

Or

• Write more tests around the URL building to ensure that relative URLs are handled correctly again.
• Release that version as 3.1.2
• Whatever fix people applied to their code to fix the regression in 3.1.1 would still be valid in 3.1.2, so it wouldn't break people's code again. It would just make the upgrade from 3.1.0 or earlier to 3.1.2 painless.

Maybe option 2 is a better way to go? Those affected, which do you prefer?

[alexlafroscia]

I also may be confused about just how this broke on people, too. I think I need to write some more test cases for more combinations to see what the expected and actual behaviors are right now and whether they make sense.

[mydea]

I have already updated our app's code, so I'm not really affected anymore anyhow. I do think it would be nice to use option 2, but not sure if the effort is worth it (no clue how much work this would entail). From my perspective, option 1 would also be OK, if it is easier to implement.

[Emrvb]

@alexlafroscia I explained what broke. It's even in the commit message "fix: don't append leading '/' when building url".

An important question here is, is appending the leading '/' a bug or not. You could argue it is, because it prevents you from using relative urls. However, ember-data's (REST)Adapter appears to be very explicit in appending that leading slash.

I would expect both (ember-data and ember-ajax) to behave the same (considering they're both using the host/namespace properties). Now I don't know who started the host/namespace thingy and who copied it, but changing the behavior should be a collaborated effort.

In my opinion: at this time, this behavior shouldn't be in any version.

I'm not sure how to version that though -- is going back to the previous behavior also a breaking change?

Generally speaking, no. Unless the broken version doesn't get unpublished soon enough and the workaround people are using would break things again upon reverting.
In this case, the workaround doesn't seem to conflict with the original behavior.

[alexlafroscia]

Yeah, after thinking about it more it doesn't seem like there's conflicting behavior. It's just a bug. I'm going to write some tests to cover this and release an update to fix it.

I really appreciate the help people have given and the patience while it's been broken!

[alexlafroscia]

By any chance, could anyone try out ember-ajax@3.1.2 with the old versions of their URLs that do not include the leading /?

@pepke41 and I spent a few hours this evening trying to figure out how to reproduce this bug and have not been able to. We wrote some additional test cases to attempt to mirror the host/namespace combinations that people have mentioned and just can't get a test to produce an unexpected result. You can find the tests we wrote in #399

I tried taking the most recent tests and running them against the addon directory from from v3.1.1 and there are a few test failures that would suggest that in some cases, the host setting on the service was being ignored in v3.1.1.

That behavior seems aligned with the original situation described in this issue -- app was introduced because the host setting was ignored, meaning the rest of the URL was interpreted as being relative, meaning it was added to the base URL which included app.

Since the tests all pass on v3.1.2, that would lead me to believe that the change released in that version fixes this issue, but I would love to either confirm that's true with someone that was bitten by this, or have someone suggest a failing test case that we aren't currently covering.

[Emrvb]

@alexlafroscia

Still broken. You fixed an entirely different issue.

Regardless of a specified host or namespace, ember-ajax used to make sure all paths would start with a forward slash, effectively preventing the use of relative urls.

Again, while this could be considered a bug, ember-data works just like this.

Considering how easy it is to reproduce and how completely unrelated your fix was, are you sure understand the problem?

[alexlafroscia]

@Emrvb The tone you are giving off to a group of people who are volunteering their time to write and maintain software for you to use is not appreciated.

You fixed an entirely different issue.

I really feel like you’re talking about a different problem than the one originally reported by the user here. It would be very helpful to the people spending their free time trying to solve this problem if you would not muddle the conversation in that way.

The original issue here mentions having a host and namespace set, and the host being ignored, which causes the app’s mount point to be used as the start of the URL and the namespace and URL path provided in the request to be appended to it. That is the problem I am trying to solve right now. The fact that relative URLs used to be made absolute implicitly is, as far as I can tell, something separate and deserving of a separate issue.

I do see the problem that you are talking about with regard to previously not supporting relative paths and that we now do. To me, this kind of falls into “depending on a bug that is now fixed” territory. You are essentially saying, from what I can tell, that supporting relative URLs is a regression.

I understand it is a breaking change. I understand that it should have been released as a major version. Your insistence that these two bugs are in fact the same issue is what I do not understand and frankly has made this much harder to solve.

Considering how easy it is to reproduce and how completely unrelated your fix was, are you sure understand the problem?

Since you clearly have such a strong understanding of this problem, I would be more than happy to review a pull request from you.

[alexlafroscia]

Since the root of the problem here seems to be a change in the way that ember-ajax handles relative URLs, I couldn't see a way of supporting both the old and new behavior at the same time or issuing a deprecation warning or anything. I ended up going with my initial approach to fixing the issue, outlined above.

v3.1.3 was released that reverts the issue.

v4.0.0 was released from master, including the changed behavior and the appropriate major version bump.

[Emrvb]

@alexlafroscia I'm sorry you took offense of my tone. I'll try to be a little less blunt now (and in the future).

I appreciate the time you took to write up the constructive criticism. I would like to respond with my point of view. If you feel like this comment shouldn't be here I totally understand and I don't mind if you delete it.

---

The issue reported is about missing leading slashes. Users have this problem with or without a namespace set. You decided to focus solely on the host+namespace situation and you completely ignored my comment regarding leading slash behavior in general.

To prevent "muddling" you could have mentioned you were having a problem specifically with the host+namespace combination and that you would have liked to have the leading slash behavior discussion somewhere else.

I seriously doubt the original reporter got bitten by the bug you fixed. That issue was present before 3.1.0 and in 3.1.1 the regex check became slightly stricter. I think it is more likely the reporter didn't actually specify the host.

Finally, I certainly wouldn't have had a problem with contributing a patch. But I didn't feel it was up to me to decide relative urls were not to be supported.

[alexlafroscia]

To prevent "muddling" you could have mentioned you were having a problem specifically with the host+namespace combination and that you would have liked to have the leading slash behavior discussion somewhere else.

You're right about this, for sure. It took me a while to realize there were multiple issues at play here, leading to the confusion. By the time I finally did, things had already gotten a little out-of-hand.

I think it is more likely the reporter didn't actually specify the host.

I'm going to allow @mydea to clarify this because they show in their code example that they do provide a host, and I was able to re-create an error like theirs on 3.1.1

[mydea]

Thank you for all the time looking into this!

We do provide a host, but it is '' in production - as there, it is on the same URL. e.g. https://mydea.com/app is the app, and https://mydea.com/api is the API. During development, the host is a different URL.

[Emrvb]

@alexlafroscia I'm glad we were able to talk this through. Thank you for your time and effort.