Relative Location Header

[TheSharpieOne]

Currently the location header returned in the response (which indicates to poll) expects a fully qualified URL (or absolute URL). Per the HTTP spec, a relative URL can be provided and should be supported

sdk-js/packages/api-core/src/api.js

Lines 119 to 129 in 77b69f2

	getLocation(response) {
	let location = false;
	if (response.config.getHeader) {
	location = response.config.getHeader(response, 'Location');
	} else {
	location = response.headers.location || response.headers.Location;
	}
	return location;
	}

The library should check for relative URLs and return a fully qualified URL to be polled.

[KaseyPowers]

Wouldn't a relative URL given here be treated the same as the relative URLs we generate for the initial call?

Is this the reason we have this in our ms api definition?

[TheSharpieOne]

When we get back a relative url in the location header, such as abcdefg, we make a request to that url as if it was relative to the current path/page when it should be based on the original request url.
Example:
Current page: /current/browser/page
Original API: /api/v1/uploads/resumeable/
Response Location header: abcdefg

Where it currently polls: /current/browser/abcdefg
Where it should poll: /api/v1/uploads/resumeable/abcdefg

For microservices, we (for some reason) just use the same url no matter what the location header is IIRC.