action #119200
closedopenQA barfs on very long POST requests (>8190 chars)
0%
Description
Just ran into a very fun corner case on our (Fedora's) openQA. For our update tests, one of the params we POST is a list of all the builds in the update (because the builds in updates can be edited, so we want to be sure openQA tests exactly the builds that were in the update at the time the job was created, and we know exactly what builds it tested).
So, someone created an update with a LOT of builds in it. And that meant the POST request to schedule one flavor for that update (the flavor with the longest name...) was just over 8190 characters long.
It seems like 8190 characters is a significant limit. For a start, it's Apache's default limit for request length, so initially this request just got a 414 from Apache, without reaching openQA at all. So I changed the LimitRequestLine setting in Apache to 16000. That caused the request to make it through to openQA, but openQA itself barfed on it. It gives a 200 response, but the content is not JSON like it ought to be, it's the HTML of the homepage. And it didn't schedule any jobs.
In the end, to get things working again, I had to do an awful hack to the scheduler code to drop some params we usually set in order to get the request length just under 8190 chars, and that made openQA complete it successfully.
I took a quick look through openQA and Mojolicious to see if I could find somewhere there with this same 8190 character request length limit, but didn't find it. So either it's in something lower than Mojolicious, or I didn't find it.
Still, I can think of another way to solve this: we could allow the use of form data for POSTing jobs, as well as/instead of query parameters. The size limits for form data are way bigger. I'm kinda worried that if somebody creates a Fedora update with even more packages, I could really be stuck :D
I'll see if I have the chops to send a PR for this next week if I have the time.
Updated by AdamWill over 1 year ago
So it looks like this might actually Just Work(tm) without any change needed server side, because mojolicious is awesome and when you get a request's parameters, it actually pulls all params from the query URI and any form data:
https://docs.mojolicious.org/Mojo/Message/Request#params
so, it might be the case that we only need to change this in the client(s).
Updated by AdamWill over 1 year ago
It's funny, the deeper I look into this, the deeper it's all there already. The python client already actually supports using data instead of query params - you just pass the data arg to openqa_request() instead of the params arg. So I think literally all this needs for Fedora is to change the scheduler from doing client.openqa_request('POST', 'isos', fullparams) (the third arg is params) to doing client.openqa_request('POST', 'isos', data=fullparams). I just tried that and it seemed to work fine.
Only thing left to check, I guess, is whether the perl client stuff also supports this, if so, there's nothing to do...
Updated by AdamWill over 1 year ago
...aaand if I'm reading https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/CLI/api.pm#L50 right, openQA's own perl client code already always sends params as form data. So, I think there's literally nothing to do here. :D