Mocktail and Content-Type

[ivan-ushakov]

Here is file produced by SWHttpTrafficRecorder:

GET
//getFile.php\?filename=.*$
200
application/zip;base64
Content-Type: application/zip

As you see we have Content-Type = application/zip from request's header and also content type generated by recorder. With current OHHTTPStubs implementation first value application/zip;base64 will be overwritten by application/zip and base64 decoding will not happen. This leads to bug.

Could you tell me who is wrong is this situation, OHHTTPStubs or SWHttpTrafficRecorder?

[AliSoftware]

Hi

To be honest I'm not the one who implemented the Mocktail subspec in OHHTTPStubs (that came with a PR) and I don't really know much about the Mocktail file format spec, so not sure which one is right or wrong.

Maybe @JinlianWang (who implemented Mocktail support in the first place via #108) or @Ashton-W (who made some modifications about it in #172) might know better?

[AliSoftware]

Also, what you describe seems quite similar to what @Ashton-W mentioned in #170 (which led to the PR he did in #172). If I understand the comments correctly, Mocktail allows headers to either be specified using format "Header: Value" or just "Value" (which should then be interpreted as an implicit Content-Type header).

Maybe we oversaw a case where some Mocktail files mix both of those formats, with some lines using just "Value" ("application/zip;base64") and "Header: Value" ("Content-Type: application/zip")?

But even if that's the case, it seems quite strange to me that SWHttpTrafficRecorder would generate files using a mix of the two header formats in the same file, especially if both lines are meant to both declare a Content-Type header (one implicitly, the other explicitly)… and the values for those don't match… so maybe that strange format mix is an issue on SWHttpTrafficRecorder's side after all?

[ivan-ushakov]

@AliSoftware I created the same issue for SWHttpTrafficRecorder but I still don't have any response.

[JinlianWang]

@AliSoftware is right; the issue shall be on the SWHttpTrafficRecorder side. @ivan-ushakov sorry that I may not be able to handle any issue for that repo in the near future, in the process of archiving/retiring the project. Please find other tools that may work for similar purpose or feel free to find a solution and share with community if possible.