Cannot forecast prices for more than 13 services

[paroxp]

What

We're hitting an issue, when requesting more than 13 services to be forecasted by the API. This is not an issue with paas-billing per se, as we believe we're hitting haproxy's header size limit which is 8K per GET request.

We believe this could be sortable by changing the method on the request to POST.

[46bit]

I seem to be able to reproduce this, with 13-ish events.

https://admin.london.cloud.service.gov.uk/calculator?rangeStart=2019-04-01&rangeStop=2019-04-30&items%5B0%5D%5BplanGUID%5D=f4d4b95a-f55e-4593-8d54-3364c25798c4&items%5B0%5D%5BnumberOfNodes%5D=1&items%5B0%5D%5BmemoryInMB%5D=64&items%5B1%5D%5BplanGUID%5D=f4d4b95a-f55e-4593-8d54-3364c25798c4&items%5B1%5D%5BnumberOfNodes%5D=1&items%5B1%5D%5BmemoryInMB%5D=1024&items%5B2%5D%5BplanGUID%5D=c84d1bef-9500-4ce9-88b2-c0bd421bbf8a&items%5B2%5D%5BnumberOfNodes%5D=1&items%5B2%5D%5BmemoryInMB%5D=&items%5B3%5D%5BplanGUID%5D=2f6df103-8216-4bc4-bb38-a6422e03c981&items%5B3%5D%5BnumberOfNodes%5D=0&items%5B3%5D%5BmemoryInMB%5D=&items%5B4%5D%5BplanGUID%5D=63cdac92-9e44-42a6-ba3f-7be3dccf5dc6&items%5B4%5D%5BnumberOfNodes%5D=0&items%5B4%5D%5BmemoryInMB%5D=&items%5B5%5D%5BplanGUID%5D=242a4782-7454-4ff4-93b2-dd88b333cb46&items%5B5%5D%5BnumberOfNodes%5D=0&items%5B5%5D%5BmemoryInMB%5D=&items%5B6%5D%5BplanGUID%5D=f4d4b95a-f55e-4593-8d54-3364c25798c4&items%5B6%5D%5BnumberOfNodes%5D=32&items%5B6%5D%5BmemoryInMB%5D=128&items%5B7%5D%5BplanGUID%5D=f4d4b95a-f55e-4593-8d54-3364c25798c4&items%5B7%5D%5BnumberOfNodes%5D=128&items%5B7%5D%5BmemoryInMB%5D=2048&items%5B8%5D%5BplanGUID%5D=4edc975c-3f07-46f1-bd87-ecb35b76298f&items%5B8%5D%5BnumberOfNodes%5D=0&items%5B8%5D%5BmemoryInMB%5D=&items%5B9%5D%5BplanGUID%5D=b6949ea7-5c98-4c69-b981-4b5318ea8b7c&items%5B9%5D%5BnumberOfNodes%5D=1&items%5B9%5D%5BmemoryInMB%5D=&items%5B10%5D%5BplanGUID%5D=2f6df103-8216-4bc4-bb38-a6422e03c981&items%5B10%5D%5BnumberOfNodes%5D=0&items%5B10%5D%5BmemoryInMB%5D=&items%5B11%5D%5BplanGUID%5D=43b01f78-0c9f-482e-b77f-e28189ccd870&items%5B11%5D%5BnumberOfNodes%5D=0&items%5B11%5D%5BmemoryInMB%5D=&items%5B12%5D%5BplanGUID%5D=b6949ea7-5c98-4c69-b981-4b5318ea8b7c&items%5B12%5D%5BnumberOfNodes%5D=1&items%5B12%5D%5BmemoryInMB%5D=&items%5B13%5D%5BplanGUID%5D=065a7de5-28e8-4de1-8a39-4b4f752e2f2f&items%5B13%5D%5BnumberOfNodes%5D=0&items%5B13%5D%5BstorageInMB%5D=5120

I'll try and fix.

[46bit]

@richardTowers brought up an important caveat to using POST. Right now the calculator links are shareable, but that won't be the case if we switch to using POST. He suggested compressing the data with gzip and base64, which in my example above reduces the size by about 2/3rds. That would allow for 35+ services before this bug emerged.

[46bit]

Fixing this using compression would be awkward. The calculator and the billing would need to be using compression, and that's problematic because we'd need to use javascript in the calculator to compress the query string. This sounds too big for me right now.