[8.x] [HTTP] Default to `oldest` in dev (elastic#203225) (e…

…lastic#204609)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[HTTP] Default to `oldest` in dev
(elastic#203225)](elastic#203225)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Jean-Louis
Leysens","email":"jeanlouis.leysens@elastic.co"},"sourceCommit":{"committedDate":"2024-12-17T16:10:34Z","message":"[HTTP]
Default to `oldest` in dev (elastic#203225)\n\n## Summary\r\n\r\nChanges the
default HTTP version resolution in dev to `oldest`
(matches\r\nnon-dev).\r\n\r\nThe original intention was to guide
developers to always sending a\r\nversioned header when interacting with
Kibana. In practice, however,\r\ndevelopers just set-and-forget the
following configuration to get around\r\nthis
annoyance:\r\n\r\n```yaml\r\nserver.versioned.versionResolution:
'oldest'\r\n```\r\n\r\n...undoing the original intention. Having this
guidance does not justify\r\nthe confusion/annoyance that this dev-only
default creates and so this\r\nproposal simply removes it.\r\n\r\nTo
better guide developers we can consider other options like:
make\r\n`version` required in core's HTTP client interface (lots of
updates...),\r\ndoing something in tests, adding docs, something else or
any combo of\r\nthese.\r\n\r\nGiven the fact that developers generally
discover this workaround and\r\nundo the originally intended guidance,
I'm proposing not blocking on\r\nfirst having another approach in
place.","sha":"c1bda1d50145f764956de9ed8557bd21f6ba136f","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["discuss","Feature:http","Team:Core","release_note:skip","v9.0.0","backport:version","v8.18.0"],"title":"[HTTP]
Default to `oldest` in
dev","number":203225,"url":"https://github.com/elastic/kibana/pull/203225","mergeCommit":{"message":"[HTTP]
Default to `oldest` in dev (elastic#203225)\n\n## Summary\r\n\r\nChanges the
default HTTP version resolution in dev to `oldest`
(matches\r\nnon-dev).\r\n\r\nThe original intention was to guide
developers to always sending a\r\nversioned header when interacting with
Kibana. In practice, however,\r\ndevelopers just set-and-forget the
following configuration to get around\r\nthis
annoyance:\r\n\r\n```yaml\r\nserver.versioned.versionResolution:
'oldest'\r\n```\r\n\r\n...undoing the original intention. Having this
guidance does not justify\r\nthe confusion/annoyance that this dev-only
default creates and so this\r\nproposal simply removes it.\r\n\r\nTo
better guide developers we can consider other options like:
make\r\n`version` required in core's HTTP client interface (lots of
updates...),\r\ndoing something in tests, adding docs, something else or
any combo of\r\nthese.\r\n\r\nGiven the fact that developers generally
discover this workaround and\r\nundo the originally intended guidance,
I'm proposing not blocking on\r\nfirst having another approach in
place.","sha":"c1bda1d50145f764956de9ed8557bd21f6ba136f"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/203225","number":203225,"mergeCommit":{"message":"[HTTP]
Default to `oldest` in dev (elastic#203225)\n\n## Summary\r\n\r\nChanges the
default HTTP version resolution in dev to `oldest`
(matches\r\nnon-dev).\r\n\r\nThe original intention was to guide
developers to always sending a\r\nversioned header when interacting with
Kibana. In practice, however,\r\ndevelopers just set-and-forget the
following configuration to get around\r\nthis
annoyance:\r\n\r\n```yaml\r\nserver.versioned.versionResolution:
'oldest'\r\n```\r\n\r\n...undoing the original intention. Having this
guidance does not justify\r\nthe confusion/annoyance that this dev-only
default creates and so this\r\nproposal simply removes it.\r\n\r\nTo
better guide developers we can consider other options like:
make\r\n`version` required in core's HTTP client interface (lots of
updates...),\r\ndoing something in tests, adding docs, something else or
any combo of\r\nthese.\r\n\r\nGiven the fact that developers generally
discover this workaround and\r\nundo the originally intended guidance,
I'm proposing not blocking on\r\nfirst having another approach in
place.","sha":"c1bda1d50145f764956de9ed8557bd21f6ba136f"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>

packages/core/http/core-http-server-internal/src/http_config.test.ts

@@ -517,9 +517,9 @@ describe('versioned', () => {
     ).toThrow(/failed validation/);
   });
 
-  it('defaults version resolution "none" when in dev', () => {
+  it('defaults version resolution "oldest" when in dev', () => {
     expect(config.schema.validate({}, { dev: true })).toMatchObject({
-      versioned: { versionResolution: 'none' },
+      versioned: { versionResolution: 'oldest' },
     });
   });
 });

packages/core/http/core-http-server-internal/src/http_config.ts

@@ -216,15 +216,15 @@ const configSchema = schema.object(
        * Which handler resolution algo to use for public routes: "newest" or "oldest".
        *
        * @note Internal routes always require a version to be specified.
-       * @note in development we have an additional option "none" which is also the default in dev.
+       * @note in development we have an additional option "none".
        *       This prevents any fallbacks and requires that a version specified.
        *       Useful for ensuring that a given client always specifies a version.
        */
       versionResolution: schema.conditional(
         schema.contextRef('dev'),
         true,
         schema.oneOf([schema.literal('newest'), schema.literal('oldest'), schema.literal('none')], {
-          defaultValue: 'none',
+          defaultValue: 'oldest',
         }),
         schema.oneOf([schema.literal('newest'), schema.literal('oldest')], {
           defaultValue: 'oldest',