When sending a POST to /slides/{name}/Png requesting PNGs of a presentation, the response can be a PNG or a ZIP file - depending on the source file. This is an inconsistent API.
Recently, this changed such that the response is a PNG file if the presentation has 1 slide/page only but a ZIP file of the presentation has more than one slide/page.
On top, the Header of the response still indicates that the response is a ZIP file. See last line of the example header:
Server: Kestrel
Strict-Transport-Security: max-age=2592000
Date: Tue, 05 Jul 2022 07:52:12 GMT
Access-Control-Expose-Headers: Content-Disposition
Content-Length: 2596
Content-Type: application/octet-stream
Content-Disposition: attachment; **filename=16-10_1page.zip; filename*=UTF-8''16-10_1page.zip**
This is an inconsistent response.
It can’t be expected that the requesting service knows about the number of pages in the document.
We actually don’t know and we don’t want to send another request upfront to get the information such that we know what to expect from the above API call. That’s why we rely on the response Header to give such information correctly.
This is easy to reproduce:
- Upload the two powerpoint files in the attached Testdata.zip (42.7 KB) file. One has 1 page, the other one 2 pages
- POST to
/slides/{name}/Png
for each of the files
Check the response: - For the single page powerpoint file, the response is a PNG file even though the Header says it’s a ZIP file
- For the two page file, the response is a ZIP file.