More endpoints that use DELETE with body

[jakub-bochenski]

Current Behavior

v1/tag
v1/tag/$tag_name/policy
v1/tag/$tag_name/project

Expected Behavior

As clarified by RFC 9110 using method body in DELETE requests is not interoperable.

Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack

Dependency-Track Version

4.7.x

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[LWChris]

Although RFC 9110 continues in the very next sentence

A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.

So it explicitly mentions that a server may "indicate out of band that such a request has a purpose and will be adequately supported", which DependencyTrack does.

I agree however that

"content received in a DELETE request [...] cannot alter the meaning [...] of the request"

is pretty clear.

Another point is that clients may not support DELETE with a body. .NET's HttpClient for example does not even have a convenience method DeleteAsync with a content parameter (unlike PostAsync); you have to craft your own HttpRequestMessage from scratch to even operate the API. And I others might not even allow sending such a request at all.

The whole API around tags is a mess that (much like many other endpoints of this API) ignores a lot of established best practices of REST APIs.

The "standard" would be:

GET /v1/tags
POST /v1/tags/{tagName}
POST /v1/tags
DELETE /v1/tags/{tagName}
GET /v1/tags/{tagName}/projects
DELETE /v1/tags/{tagName}/projects/{projectId}
GET /v1/tags/{tagName}/policies
DELETE /v1/tags/{tagName}/policies/{policyId}

GET /v1/projects/{projectId}/tags
POST /v1/projects/{projectId}/tags/{tagName}
POST /v1/projects/{projectId}/tags
DELETE /v1/projects/{projectId}/tags/{tagName}
PUT /v1/projects/{projectId}/tags

GET /v1/policies/{policyId}/tags
POST /v1/policies/{policyId}/tags/{tagName}
POST /v1/policies/{policyId}/tags
DELETE /v1/policies/{policyId}/tags/{tagName}
PUT /v1/policies/{policyId}/tags

I have never had to work with a REST API that requires so much custom code to accomodate for all the untypical behavior or expectations like DependencyTrack's API. v2 may hopefully one day straighten that out but it's going to be a lot of breaking changes if you want to consider the usual best practices.

[jakub-bochenski]

So it explicitly mentions that a server may "indicate out of band that such a request has a purpose and will be adequately supported", which DependencyTrack does.

Which forces the client to only make requests directly to the server. Most companies would not allow deploying DT without some kind of fronting server for security reasons.

[LWChris]

Yeah as I said, I think

"content received in a DELETE request [...] cannot alter the meaning [...] of the request"

is a dead giveaway that the current API is not designed according to what the spec authors had in mind for DELETE messages.

[nscuro]

The intention is to clean these things up gradually by initially only creating new endpoints in a v2 API, and then gradually moving old functionality from v1 over, with appropriate deprecation notices etc.: https://github.com/DependencyTrack/hyades/blob/main/docs/architecture/decisions/007-spec-first-rest-api-v2.md

The DELETE-with-body pattern existed for other endpoints already, so it was used for tag bulk operations as well. This pattern will not continue to exist in v2.