/exec and /run paths should use POST, not GET

[lavalamp]

GET should never cause a mutation. Otherwise a search engine will pwn you.

Forked from #10351.

[davidopp]

You filed this as node, but it's actually master, right?

BTW do you think this is the only 1.0-worth issue mentioned in #10351?

[lavalamp]

I split it off because it's separable. I think the paths are in both master and node, but I need to double check master and I got distracted. :)

[lavalamp]

Yes, there's a /exec on master, too: https://github.com/GoogleCloudPlatform/kubernetes/blob/461fc2b01b29f17b8aebabf463c3fa7fd656d53e/pkg/master/master.go#L467

Also that /portforward should probably also not allow GET.

[davidopp]

Thanks (and sorry, I meant also master)

[lavalamp]

@ncdc @smarterclayton Question for one of you: if we switch /exec and /portforward to accept POST only (and not GET), will that break any of your tooling?

@nikhiljindal agreed to take this on-- ideally we'll change kubelet & apiserver to accept both, change kubectl to start sending POSTs, and in a few weeks remove GET support from our servers.

[smarterclayton]

It would break our backwards compatibility to clients. Can we preserve that backwards compat via a flag?

On Jun 25, 2015, at 5:37 PM, Daniel Smith notifications@github.com wrote:

@ncdc @smarterclayton Question for one of you: if we switch /exec and /portforward to accept POST only (and not GET), will that break any of your tooling?

@nikhiljindal agreed to take this on-- ideally we'll change kubelet & apiserver to accept both, change kubectl to start sending POSTs, and in a few weeks remove GET support from our servers.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Important note - we still need to pass all params to both as query (since the body is hijacked).

And we're ok with the change, but we need some leve of back compat available for upgrade. The easier we can make that (even if we have to carry a patch for back compat) the better for us. Doesn't have to be a switch.

[smarterclayton]

I remember what the concern was - whether most proxies would properly support connection upgrade on a POST. We haven't extensively tested whether POST would work, but we require support for at least HAProxy and an F5 proxy in front of our exec/portforward endpoints. So we probably need to test that.

----- Original Message -----

It would break our backwards compatibility to clients. Can we preserve that
backwards compat via a flag?

On Jun 25, 2015, at 5:37 PM, Daniel Smith notifications@github.com wrote:

@ncdc @smarterclayton Question for one of you: if we switch /exec and
/portforward to accept POST only (and not GET), will that break any of
your tooling?

@nikhiljindal agreed to take this on-- ideally we'll change kubelet &
apiserver to accept both, change kubectl to start sending POSTs, and in a
few weeks remove GET support from our servers.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

We have to support GET for web sockets in browsers. There is no other way for a browser to open a websocket to exec or logs. Logs are extremely valuable, exec will be more valuable.