1430096 - Change references schema to denote some parameters should not be encoded

Status: RESOLVED FIXED

(Taskcluster :: Services, enhancement)

Description

[:Eli Perelman]

In order to completely remove all hardcoded URLs in the UI, we need a way to handle in the client that some query string parameters should be raw/non-encoded vs. the existing behavior which encodes all parameters.

From taskcluster-tools[1]:

> We could use queue.buildUrl, but this creates URLs where the artifact name has slashes encoded.
> For artifacts we specifically allow slashes in the name unencoded, as this make things like
> `wget ${URL}` create files with nice names.

https://github.com/taskcluster/taskcluster-tools/blob/cc5860196b45e3c36f4e9b7909b7c8ee1ba6a22c/src/components/ArtifactList/index.js#L68-L70

Comment 1

[:Eli Perelman]

I think this is no longer completely necessary from taskcluster-tools' perspective now that we are going to use tc-lib-urls.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Eli, can you explain what this means a bit more?

I thought we had some way of indicating that a parameter consumed the remainder of the path and thus didn't need `/` encoded, but looking through tc-lib-api I can't find it.  Is that what you're looking for?

 - a way to indicate a parameter need not be encoded (e.g., `/:someParam*`) in lib-api
 - store that in the references
 - interpret that in the clients such that those parameters are not `/`-encoded

Comment 3

[:Eli Perelman]

I *think* that is what was needed here. If you see the link in the description, there is a comment with Jonas's notes about why this was needed, along with the specific usage. I think the point is to say that a parameter is raw and shouldn't go through the codec process.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Oh indeed:
   route: '/task/:taskId/runs/:runId/artifacts/:name(*)',
so the syntax exists (and the regexp in util.js allos it).  It doesn't look like tc-lib-api actually does anything with the value, though.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

So, tc-lib-api does actually (indirectly) handle this syntax -- we used it in worker-manager, for example, to allow workerPoolId to be given with a /

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

So, tc-lib-api does actually (indirectly) handle this syntax -- we used it in worker-manager, for example, to allow workerPoolId to be given with a /
https://github.com/taskcluster/taskcluster/blob/810230f0afdf5d0acbb8e34a4be681ab1edd84fa/services/worker-manager/src/api.js#L134

This is not handled by the client libraries, though. We could potentially fix that.

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

So the "potentially" here would be to generate paths like

/worker-pool-errors/proj-foo/bar

instead of

/worker-pool-errors/proj-foo%2Fbar

I don't think that's worthwhile, and it brings a risk of generating ambiguous routes. Clients should generate maximally unambiguous URLs.