$resource strips port from url

[thughes]

As discussed in https://groups.google.com/forum/?fromgroups#!topic/angular/18aO0bIlEm0%5B1-25%5D, if you include a port in the URL passed to $resource, it gets stripped since everything with a colon is substituted.

Escaping the colon works, but that makes it a pain to use the same URL with $http (which doesn't seem to understand the escaping).

In general you should be using relative URLs, but the use case for needing the full path is for cross origin requests.

[ProLoser]

Is this a bug or... what? Seems redundant to #942

Or are you making a bug asking specifically what @JamesDunne proposed

[thughes]

It's supposed to be a bug. It's the same as #942, but that issue was closed with "you need to use escaping". My point here was to illustrate that escaping isn't really a solution (every first time user of angular using a port number will hit it and $http doesn't understand the escaping so you can't use the same URL).

@JamesDunne's proposal seems fine, but I wasn't advocating any particular solution.

[vitch]

I've just run into this problem too. Additionally, it doesn't seem to work escaping the colon with a backslash (using 1.0.2)

[frapontillo]

The backslash escaping does not work for me; I'm using v1.0.2.

[earlyriser]

I'm having the same problem: escaping : doesn't work and I'm using 1.0.2

Do you have found any solution?

Trying to access a url of this kind: http://subdomain.domain.com:9000/some/parameters

[frapontillo]

A workaround would be to include a port parameter with a custom fixed value, such as http://subdomain.domain.com:port/some/parameters.

[oilart]

Hi, that is really confusing problem. To fix that I was using {port} parameter in all resource instances as others do but, code gets really messy. So, I decided to have a single URL address in the configuration and came up with another solution, so try to use this:

$resource('http://localhost:XXXX\:XXXX/api/entities'); 

Test (in Coffeescript)

describe "Resource port replacment test", ->
  entity=null

  beforeEach module("YourApp")
  beforeEach inject(($resource, $httpBackend) ->
    @entity = $resource 'http://localhost:56789\:56789/api/entities'
    @httpBackend = $httpBackend
    @httpBackend.expectGET('http://localhost:56789/api/entities').
          respond(200, '1'))

  afterEach ->
    @httpBackend.verifyNoOutstandingExpectation()
    @httpBackend.verifyNoOutstandingRequest()

  it "checking the address", ->
    @entity.query {}
    @httpBackend.flush()

It's another trick, but works fine for me. Hope you guys can fix it in the next release.

Cheers

[cmdrkeene]

There is a also a disparity between how $resource and $http handle this.

For example, if you use a common config variable with the double port (http://localhost:3000\:3000) as proposed above:

• $http requests go to http://localhost:3000:3000
• $resource requests go to http://localhost:3000

UPDATE: This was mentioned in the original ticket. Sorry for the repost, but it's a major pain for cross-domain and local development.

[xealot]

Ran into this issue today, was able to solve with the following:

var escapedUrl = window.API_PREFIX.replace(/:([^\/])/, '\\:$1');

(Note: I'm sure that's not the best way to do it)

It seems that a : is a poor use for a string interpolation marker here since the chance of needing to specify hostname in the ajax call is high. Especially with the increasing popularity of projects completely decoupled from their associated API.

While I imagine regressions would make it infeasible to change at this point a much more acceptable token would be something like /api/{userId} which is pretty popular as well and unused in the URL. Colon was most likely chosen because it's a common paradigm in a lot of server-side URL dispatching and routing applications but the character is heavily reserved in URL schemes.

[pkozlowski-opensource]

You can escape port number using double \\, ex.: http://198.61.201.6\\:8000/api/v1-dev/trackers
Here is the jsFiddle: http://jsfiddle.net/mkLzh/

Docs were updated in c398d7d thnx to @jsyrjala !
On-line docs should be updated soon as well.

[TLmaK0]

I think you can provide a better solution. The behaviour is different from $http. This is a workaround and very ugly. You should check "protocol://server:port". Are you really thinking that someone could use :port as variable? There are a lot of people asking for this problem. Don't fix it now, but keep it open please.