This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] add Request type json check in json_login
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no, unreleased feature
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | -
follow up to https://github.com/symfony/symfony/pull/22425 to limit the `UsernamePasswordJsonAuthenticationListener` to only requests with appropriate JSON content type.
I am not entirely happy with this implementation but mostly because Symfony out of the box only provides very limited content type negotiation. I guess anyone that wants to tweak the content negotiation will simply need to ensure the Request::$format is set accordingly before the code is triggered.
Commits
-------
045a36b303 add Request type json check in json_login
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Add missing normalizer options constants
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | not really
| New feature? | yesish, but for 3.3 as those options were added on this branch and not released yet
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22537#discussion_r113719848
| License | MIT
| Doc PR | N/A
As seen in https://github.com/symfony/symfony/pull/22537#discussion_r113719848.
@dunglas : I'm not sure about the exposing the `key_type` option as a constant in `ArrayDenormalizer`/`AbstractObjectNormalizer`, as it looks more or less like a detail of the AbstractObjectNormalizer implementation, but anyway it should be in 3.2 if we add it, so I haven't included it here.
However, I wonder if this option shouldn't directly accept a string too, rather than just a `Symfony\Component\PropertyInfo\Type` instance if we want to consider this option "public"?
Commits
-------
b0c414f2c8 [Serializer] Add missing normalizer options constants
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Serializer] Allow to pass csv encoder options in context
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
CSV contents typically are provided by one or many third-parties, not always allowing you to get control over the provided format. In case you need to import csv files with different formats, either you have to instantiate a decoder yourself/inject it instead of the main serializer instance, either you need another serializer instance with a differently configured csv encoder registered within.
This PR allows to configure any encoder option through the context, so you can keep injecting and using the same serializer instance.
Commits
-------
10a76aac15 [Serializer] Allow to pass csv encoder options in context
This PR was merged into the 2.8 branch.
Discussion
----------
Allow Upper Case property names in ObjectNormalizer
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22547
| License | MIT
Same problem that has been fixed here https://github.com/symfony/symfony/pull/22265
and here https://github.com/api-platform/core/pull/1037
ObjectNormalizer returns $id instead of $Id. It is bad naming convention, but is possible
```php
class Entity {
protected $Id;
public function getId()
{
return $this->Id;
}
}
```
Commits
-------
b2b4faa3c0 Allow Upper Case property names in ObjectNormalizer
This PR was merged into the 2.8 branch.
Discussion
----------
[VarDumper] Add iconv dependency
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Alternative to #20927.
I still think adding `@requires extension iconv` to the related tests would be nice though: on some PHP setups the iconv extension is not available by default, those tests will fail and result in red errors when running the test suite, even when working on something unrelated. The test would still run on CI so it's fine IMO.
Should I add `ext-iconv` and/or `symfony/polyfill` to `require-dev`?
/cc @nicolas-grekas
Commits
-------
13f17079ef Add iconv extension to suggested dependencies
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] Handle bad request format in json auth listener
| Q | A
| ------------- | ---
| Branch? | master (3.3)
| Bug fix? | yesish
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
In https://github.com/symfony/symfony/pull/22034, I wondered myself if we shouldn't throw a dedicated exception to handle bad formatted requests and give more inputs to the client by returning a 400 response with an explicit message.
~~Here is a suggestion, introducing a new `BadRequestFormatException` and using it in `UsernamePasswordJsonAuthenticationListener` whenever there is no custom failure handler set (but someone using its own handler should be able to treat the failure properly too).~~
As discussed with @chalasr , it seems better to directly throw a `BadRequestHttpException` as it's actually out of the whole security process. PR updated.
Commits
-------
93a8cb9cd4 [Security] Handle bad request format in json auth listener
This PR was squashed before being merged into the 3.3-dev branch (closes#22551).
Discussion
----------
[Process] Ecaping of CLI arguments containing slashes on Windows
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22549
| License | MIT
Actually only the first argument - the command needs to be escaped but that would need another condition. I think it should be OK.
Commits
-------
0d073128de [Process] Ecaping of CLI arguments containing slashes on Windows
This PR was merged into the 3.3-dev branch.
Discussion
----------
Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes (removing risky behavior)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | see #22530
| License | MIT
| Doc PR | n/a
This PR *prohibits* using `autoconfigure`, `_instanceof` and `_defaults` for ChildDefinition.
Additionally, I added many "integration" test cases: we need to test and prove all edge cases. These are in the `integration/` directory: the `main.yml` file is parsed and compared to `expected.yml`. Both are in YAML to ease comparing the before/after. We need to check these out and make sure they're right and we're not missing anything else.
This PR removes MANY of the "wtf" cases, but there are still 4 that I know of... and of course they all deal with parent-child stuff :).
A) [MAJOR] [autoconfigure_parent_child_tags](https://github.com/symfony/symfony/pull/22563/files#diff-fd6cf15470c5abd40156e4e7dc4e7f6d) `instanceof` tags from autoconfigure are NEVER applied to the child (you can't set `autoconfigure` directly on a Child, but you still can set it on a parent and inherit it... sneaky). We could throw an Exception I suppose to prevent this `autoconfigure` from cascading from parent to child... but it's tricky due to `instanceof`.
B( [MAJOR] [instanceof_parent_child](https://github.com/symfony/symfony/pull/22563/files#diff-14666e9a25322d44b3c2c583b6814dc2) `instanceof` tags that are applied to the parent, are not applied to the child. Again, you can't set `instanceof` directly on a Child, but you *can* set it on a parent, and have that cascade to the child. Like before, we could maybe throw an exception to prevent this.
C) [MINOR] ([autoconfigure_child_not_applied](https://github.com/symfony/symfony/pull/22563/files#diff-3372a1dcaf3af30d14a7d0a6c8bfa988)) automatic `instanceof` will not be applied to the child when the parent class has a different (non-instanceof-ed) class. If we could throw an exception for (A), then it would cover this too.
D) `_tags` from defaults are never used (unless you have inherit_tags) - fixed in #22530
A, B & C are effectively caused by there being a "sneaky" way to re-enable `autoconfigure` and `instanceof` for ChildDefinition... which opens up wtf cases.
## Wait, why not support `_defaults`, `autoconfigure` and `_instanceof` for child definitions?
1 big reason: reduction of wtf moments where we arbitrarily decide override logic. PLUS, since `_defaults`, `instanceof` and `autoconfigure` *are* applied to parent definitions, in practice (other than tags), this makes no difference: the configuration will still pass from parent down to child.
Also, using parent-child definitions is already an edge case, and this *simply* prevents *just* those services from using the new features.
## Longer reasons why
The reason behind this is that parent-child definitions are a different mechanism for "inheritance"
than `_instanceof` and `_defaults`... creating some edge cases when trying to figure out which settings "win". For example:
```yml
# file1.yml
services:
_defaults:
public: false
ChildService:
parent: parent_service
# file2.yml
services:
_defaults:
public: true
ParentService: ~
```
Is `ChildDefinition` `public: true` (so the parent
overrides the child, even though it only came from _defaults) or `public: false` (where
the child wins... even though it was only set from its _defaults)?
Or, if ParentService is explicitly set to `public: true`, should that override the `public: false` of ChildService (which it got from its `_defaults`)? On one hand, ParentService is being explicitly
set. On the other hand, ChildService is explicitly in a file settings `_defaults` `public: false`
There's no correct answer.
There are also problems with `_instanceof`. The importance goes:
> defaults < instanceof < service definition
But how do parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
Commits
-------
a943b96d42 Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console][HttpKernel] Avoid reflection-based registration for command public services
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/22410#issuecomment-298158585
| License | MIT
| Doc PR | n/a
By mapping commands ids by their alias in `console.command.ids` (even if the alias is not registered in the container for public services), then skipping reflection if the predictable alias exists as a key of `console.command.ids`.
Please note that the whole command service registration process is far from ideal.
I'm working on changing this for 3.4 in a transparent way regarding end users, leveraging PSR-11 to make the console component DI friendly, allowing to register commands as true private services (no more public aliases) and providing laziness for those.
Commits
-------
6c1b384b75 Avoid reflection-based registration for command public services
This PR was squashed before being merged into the 3.3-dev branch (closes#22564).
Discussion
----------
Fixing problem where _defaults set to null was seen as a service
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
```yml
services:
_defaults:
```
If you leave `_defaults` empty (i.e. null), you got a bad error before. Now it's better :)
Before:
>The definition for "_defaults" has no class. If you intend to inject this service dynamicall
y at runtime, please mark it as synthetic=true. If this is an abstract definition solely use
d by child definitions, please add abstract=true, otherwise specify a class to get rid of th
is error.
After:
> Service "_defaults" key must be an array, "NULL" given in "/path/to/services.yml"
Commits
-------
4b7e148a9b Fixing problem where _defaults set to null was seen as a service
This PR was squashed before being merged into the 2.7 branch (closes#22528).
Discussion
----------
[Asset] Starting slash should indicate no basePath wanted
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes-ish... and no-ish
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
**Important** View the second commit for an accurate diff. The first commit just renames some strings in a test for clarity.
When we moved `PathPackage` from `Templating` to `Asset`, we actually changed its behavior. Assume that we're deployed under a `/subdir` subdirectory:
**Before** `{{ asset('/main.css') }}` would *not* have the base path prefixed -> `/main.css`
**After** `{{ asset('/main.css') }}` *does* have the base path prefixed -> `/subdir/main.css`
3adff11d72/src/Symfony/Component/Templating/Asset/PathPackage.php (L61-L63)
This PR simply reverses that, to the *previous* behavior. This *is* a BC break... and also arguably a bug fix :). Interestingly, when we changed the behavior the first time (i.e. broke BC), I don't think that anyone noticed. It should only affect users deployed under a subdirectory.
Why do I care? I'm using the new `JsonManifestVersionStrategy` with a library that is outputting paths that *already* include my subdirectory:
```json
{
"build/main.css": "/subdir/build/main.abc123.css"
}
```
So, I do not want Symfony to detect the `/subdir` and apply it a second time.
Commits
-------
3cc096b540 [Asset] Starting slash should indicate no basePath wanted
Also, not allowing arguments or method calls for autoconfigure. This is a safety
mechanism, since we don't have merging logic. It will allow us to add this in the
future if we want to.
The reason is that parent-child definitions are a different mechanism for "inheritance"
than instanceofConditionas and defaults... creating some edge cases when trying to
figure out which settings "win". For example:
Suppose a child and parent definitions are defined in different YAML files. The
child receives public: false from its _defaults, and the parent receives public: true
from its _defaults. Should the final child definition be public: true (so the parent
overrides the child, even though it only came from _defaults) or public: false (where
the child wins... even though it was only set from its _defaults). Or, if the parent
is explicitly set to public: true, should that override the public: false of the
child (which it got from its _defaults)? On one hand, the parent is being explicitly
set. On the other hand, the child is explicitly in a file settings _defaults public
to false. There's no correct answer.
There are also problems with instanceof. The importance goes:
defaults < instanceof < service definition
But how does parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
This PR was merged into the 3.3-dev branch.
Discussion
----------
If an instanceof does not exist, throw an exception
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes-ish
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
Before, it was possible to add an `instanceof` with a non-existent class/interface. Now it throws an exception, but ONLY for conditionals set directly on a Definition: we still allow for global "automatic" instanceof definitions to be set on the `ContainerBuilder`. I'm not sure if that's correct... it makes life easier for bundler maintainers. If we also strictly validated the existence of "automatic" instanceof's, then (for example) in `FrameworkExtension`, we would need to do an `if interface_exists()` around most of the `registerForAutoconfiguration()` calls.
Commits
-------
ab0fd6e663 If a (non-global) instanceof does not exist, throw an exception
This PR was squashed before being merged into the 3.3-dev branch (closes#22570).
Discussion
----------
Fixes twig bundle project root dir discovery
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22149
| License | MIT
| Doc PR | none
<!--
- Bug fixes must be submitted against the lowest branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
TwigBundle ExtensionPass uses a directory lookup algorithm to find the composer.json file. When working under open_basedir restrictions, if the project root folder is not allowed PHP runtime to read, the composer.json will never be found, throwing PHP notices along the way and ending up using the filesystem root instead.
Since that 3.3 introduced the kernel getProjectRoot() method and kernel.project_dir variable, the TwigBundle can now leverage it, in order to get more consistent, and allow site builders to override the getProjectRoot() kernel method, hence bypass the open_basedir restrictions in reliable and safe way.
Commits
-------
3cb2e5b7dd Fixes twig bundle project root dir discovery
This PR was merged into the 3.2 branch.
Discussion
----------
[EventDispatcher] fix getting priorities of listeners during dispatch
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22520
| License | MIT
| Doc PR | -
The WebProfiler collects listener info during dispatching the `kernel.terminate` event which caused issues while retrieving priorities as the wrappers are registered instead of the real listeners.
Commits
-------
79b71c0 [EventDispatcher] fix getting priorities of listeners during dispatch
This PR was merged into the 2.7 branch.
Discussion
----------
Fix minor typo in the main README.md
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Commits
-------
8ea38b5 Fix minor typo in the main README.md
This PR was squashed before being merged into the 3.3-dev branch (closes#22531).
Discussion
----------
Throwing an exception if the class is not found
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
We now throw an exception if the user makes a mistake with their PSR-4 prefix and namespace. For example:
```yml
AppBundle\Controller\:
resource: '../../src/AppBundle/{Controller}'
public: true
```
I should not have the `\Controller` at the end of the key. Previously, it would silently not import any services from the directory. Now it throws:
> Expected to find class "AppBundle\Controller\Controller\Admin\BlogController" in file "/path/to/project/src/AppBundle/Controller/Admin/BlogController.php" while importing services from resource "../../src/AppBundle/{Controller}", but it was not found! Check the namespace prefix used with the resource.
The only "downside" is that this prevents someone from importing files from a resource that has a file with no class in it (`functions.php`). @nicolas-grekas and I decided today that we can throw an exception now to be safe, and see if anyone has that valid use-case.
Cheers!
Commits
-------
e85bcc9 Throwing an exception if the class is not found
| Q | A
| ---------------- | -----
| Bug report? | yes
| Feature request? | no
| BC Break report? | yes
| RFC? | no
| Symfony version | 2.8.19
Same problem that has been fixed here https://github.com/symfony/symfony/pull/22265
and here https://github.com/api-platform/core/pull/1037
ObjectNormalizer returns $id instead of $Id. It is bad naming convention, but is possible
```php
class Entity {
protected $Id;
public function getId()
{
return $this->Id;
}
}
```
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Remove deprecated session listener from class compiliation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22533
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
Continuation of #22535 :)
cc @chalasr
Commits
-------
dc375794a5 [FrameworkBundle] Remove deprecated session listener from class compilation
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Restore 3.2-like behavior for FormPass, to help BC with Sonata
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I tried updating a Sonata project to 3.3, and found it broken.
The issue is that Sonata uses the constructor arguments of the `form.extension` to create its own `form.extension` service - but borrows its first args from the Symfony one.
Here is the form pass doing that:
https://github.com/sonata-project/SonataCoreBundle/blob/3.x/DependencyInjection/Compiler/FormFactoryCompilerPass.php
And the implementation of the form extension:
https://github.com/sonata-project/SonataCoreBundle/blob/3.x/DependencyInjection/SonataCoreExtension.php
Question: is this covered by the BC policy? It shouldn't to me, because that would prevent *any* service reconfiguration.
Thus, I'm proposing the attached patch, which basically reverts the deprecated `FormPass` in FrameworkBundle to its 3.2 state.
I added a check to the new `FormPass` in the Form component so that it doesn't overwrite such compatibility configurations.
See for corresponding fix on https://github.com/sonata-project/SonataCoreBundle/pull/399
Commits
-------
c97b08e6c0 [FrameworkBundle] Restore 3.2-like behavior for FormPass, to help BC with Sonata
This PR was merged into the 3.3-dev branch.
Discussion
----------
[SecurityBundle] Enhance FirewallContext::getListeners()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/20417#discussion_r91704023, https://github.com/symfony/symfony/pull/20417#discussion_r91704145
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
I think @stof is right.. and the fact we can do this on master currently without the hassle.
cc @chalasr
Commits
-------
ba650783f5 [SecurityBundle] Enhance FirewallContext::getListeners()
This PR was merged into the 2.8 branch.
Discussion
----------
[EventDispatcher] fix: unwrap listeners for correct info
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | related to https://github.com/symfony/symfony/issues/22520
| License | MIT
| Doc PR | -
Fixes problem where listeners were displayed as `Symfony\Component\EventDispatcher\Debug\WrappedListener::__invoke() ` in the profiler. It now shows the correct callable.
Commits
-------
d8c5869b7c [EventDispatcher] fix: unwrap listeners for correct info
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Do not extend @final SessionListener internally
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Revert the deprecated SessionListener class body instead of extending the new one which is `@final`, avoiding the following deprecations from the debug class loader:
> User Deprecated: The Symfony\Bundle\FrameworkBundle\EventListener\SessionListener class is deprecated since version 3.3 and will be removed in 4.0. Use Symfony\Component\HttpKernel\EventListener\SessionListener instead.
> User Deprecated: The Symfony\Component\HttpKernel\EventListener\SessionListener class is considered final since version 3.3. It may change without further notice as of its next major version. You should not extend it from Symfony\Bundle\FrameworkBundle\EventListener\SessionListener.
spotted in #22533
Commits
-------
cf6110225f Do not extend @final SessionListener internally
This PR was merged into the 2.7 branch.
Discussion
----------
[Asset] Preventing the base path or absolute URL from being prefixed incorrectly
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Fixes an edge case (which I need) where the version strategy returns an absolute URL. Currently, if this happens, the baseUrl or basePath is prefixed - giving `https://baseurl.com/https://pathreturnedfromversioning.com` or `/basePath/https://pathreturnedfromversioning.com`.
I don't see any reason to prevent an absolute URL from being returned by the version strategy. And it's not a BC break, because the previous paths that were returned were nonsense.
Cheers!
Commits
-------
746c91eea4 Preventing the base path or absolute URL from being prefixed incorrectly on an absolute URL
