feat(platform-server): add option for absolute URL HTTP support #37539
Conversation
pullapprove
bot
requested review from
alxhub,
IgorMinar,
jelbourn and
pkozlowski-opensource
alan-agius4
reviewed
Jun 11, 2020
CaerusKaru
force-pushed
the
adam/http
branch
3 times, most recently
from
d0fcc97
to
ba49241
alan-agius4
reviewed
Jun 11, 2020
alan-agius4
approved these changes
Jun 11, 2020
LGTM
One small nit
CaerusKaru
force-pushed
the
adam/http
branch
4 times, most recently
from
118416b
to
e650076
|
Note: We've decided to rollback this feature in v10.0. |
14 tasks
IgorMinar
approved these changes
Jun 15, 2020
LGTM! Thanks!
Reviewed-for: public-api
jelbourn
reviewed
Jun 17, 2020
In version 10.0.0-next.8, we introduced absolute URL support for server-based HTTP requests, so long as the fully-resolved URL was provided in the initial config. However, doing so represents a breaking change for users who already have their own interceptors to model this functionality, since our logic executes before all interceptors fire on a request. See original PR angular#37071. Therefore, we introduce a flag to make this change consistent with v9 behavior, allowing users to opt in to this new behavior. This commit also fixes two issues with the previous implementation: 1. if the server was initiated with a relative URL, the absolute URL construction would fail because needed components were empty 2. if the user's absolute URL was on a port, the port would not be included
jelbourn
approved these changes
Jun 23, 2020
LGTM
Reviewed-for: public-api
pkozlowski-opensource
approved these changes
Jun 24, 2020
LGTM
Reviewed-for: public-api
kyliau
approved these changes
Jun 24, 2020
ngwattcos
added a commit
to ngwattcos/angular
that referenced
this issue
Jun 25, 2020
…lar#37539) In version 10.0.0-next.8, we introduced absolute URL support for server-based HTTP requests, so long as the fully-resolved URL was provided in the initial config. However, doing so represents a breaking change for users who already have their own interceptors to model this functionality, since our logic executes before all interceptors fire on a request. See original PR angular#37071. Therefore, we introduce a flag to make this change consistent with v9 behavior, allowing users to opt in to this new behavior. This commit also fixes two issues with the previous implementation: 1. if the server was initiated with a relative URL, the absolute URL construction would fail because needed components were empty 2. if the user's absolute URL was on a port, the port would not be included PR Close angular#37539
|
This is not working for me in |
|
It's only a part 10.1. It was reverted out of 10.0. |
|
But in the documentation it says,
So I have to keep using the universal interceptor until 10.1? |
|
Yes |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
profanis
added a commit
to profanis/angular
that referenced
this issue
Sep 5, 2020
…lar#37539) In version 10.0.0-next.8, we introduced absolute URL support for server-based HTTP requests, so long as the fully-resolved URL was provided in the initial config. However, doing so represents a breaking change for users who already have their own interceptors to model this functionality, since our logic executes before all interceptors fire on a request. See original PR angular#37071. Therefore, we introduce a flag to make this change consistent with v9 behavior, allowing users to opt in to this new behavior. This commit also fixes two issues with the previous implementation: 1. if the server was initiated with a relative URL, the absolute URL construction would fail because needed components were empty 2. if the user's absolute URL was on a port, the port would not be included PR Close angular#37539
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
In version 10.0.0-next.8, we introduced absolute URL support for
server-based HTTP requests, so long as the fully-resolved URL was
provided in the initial config. However, doing so represents a
breaking change for users who already have their own interceptors
to model this functionality, since our logic executes before all
interceptors fire on a request.
Therefore, we introduce a flag to make this change consistent with
v9 behavior, allowing users to opt in to this new behavior. This
commit also fixes two issues with the previous implementation:
URL construction would fail because needed components were empty
be included
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
The text was updated successfully, but these errors were encountered: