We're updating the issue view to help you get more done. 

Inconsistent behaviour of /ingest/addZippedMediapackage

Steps to reproduce

This issue is based on the comments upon MH-9579. The problem is that when you send a request to /ingest/addZippedMediapackage it will fail (without error!) if the order of the request parameters is “wrong” (it is correct according to the docs).

Rubens comment:

I'm reopening this because Lars' patch fixes the "addMediapackage" endpoint, but not the "addZippedMediapackage" endpoint, which is showing the same behaviour. This is particularly breaking the ingestion in Galicaster, since it is using the endpoint parameters in the "wrong" order.

On a personal note, I don't think the parameter order should be relevant in addZippedMediaPackage, because its name and purpose imply the whole Mediapackage is contained in the ZIP, so the parameters provided should be relevant to the whole MP, no matter the order they appear. I have never used the other endpoint to have a definite opinion. It might make sense to be able to send a whole Mediapackage without needing to compress it first, but I'm not sure of the implications.

Status

Assignee

Lars Kiesow

Reporter

Rubén Pérez

Severity

Incorrectly Functioning With Workaround

Tags (folksonomy)

None

Components

Fix versions

Affects versions

1.4.0

Priority

Blocker