argo-cd: Sending HTTP request using PATCH verb to REST API results in connection reset

Checklist:

  • I’ve searched in the docs and FAQ for my answer: http://bit.ly/argocd-faq.
  • I’ve included steps to reproduce the bug.
  • I’ve pasted the output of argocd version.

Describe the bug

Sending a HTTP request using the PATCH verb, the connection gets closed unexpected by the API server without any trace why.

To Reproduce

You can use curl to reproduce, below example is against local argocd-server listening on port 8081 in insecure mode:

$ curl -d '{}' -v -XPATCH http://127.0.0.1:8081/api/v1/session
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0)
> PATCH /api/v1/session HTTP/1.1
> Host: 127.0.0.1:8081
> User-Agent: curl/7.65.3
> Accept: */*
> Content-Length: 2
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 2 out of 2 bytes
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Expected behavior

Server should send back appropriate error message, such as HTTP 405 - Method not allowed or even better HTTP 501 - Not implemented if we don’t support PATCH verb at all.

Version Build from latest master:

argocd-server: v1.3.0+ac6413c.dirty
  BuildDate: 2019-11-09T12:16:35Z
  GitCommit: ac6413c63668a8850605c06f235e473e907303f7
  GitTreeState: dirty
  GoVersion: go1.12.5
  Compiler: gc
  Platform: linux/amd64
  Ksonnet Version: vdev-2019-05-15T19:48:06+0200
  Kustomize Version: Version: {KustomizeVersion:3.1.0 GitCommit:95f3303493fdea243ae83b767978092396169baf BuildDate:2019-07-26T18:11:16Z GoOs:linux GoArch:amd64}
  Helm Version: v2.13.1
  Kubectl Version: v1.15.2

Logs

Paste any relevant application logs here.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 2
  • Comments: 16 (8 by maintainers)

Commits related to this issue

Most upvoted comments

@naimo84 seems that currently it is not resolved and there is not other choice than invoking the cli…

+5
Orenus on Nov 30, 2021

sure, maybe this weekend.

+2
mmerrill3 on Jul 13, 2023

After a little more research, this happens to any verbs apparently unknown to argocd-server, so if I use arbitrary ones:

$ curl -v -XPAQ http://127.0.0.1:8081/api/version
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0)
> PAQ /api/version HTTP/1.1
> Host: 127.0.0.1:8081
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

$ curl -v -XMYVERB http://127.0.0.1:8081/api/version
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0)
> MYVERB /api/version HTTP/1.1
> Host: 127.0.0.1:8081
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Appropriate response from a “good” HTTP server:

$ curl -v -XMYVERB http://www.google.com
*   Trying 172.217.18.4:80...
* TCP_NODELAY set
* Connected to www.google.com (172.217.18.4) port 80 (#0)
> MYVERB / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Content-Length: 1591
< Date: Sun, 10 Nov 2019 18:01:42 GMT
+2
jannfis on Nov 10, 2019
Read more comments on GitHub
← argo-cd: Secret key can not be omitted
argo-cd: ServerSideApply fails with "conversion failed" →