AliSoftware / OHHTTPStubs

Stub your network requests easily! Test your apps with fake network data and custom response time, response code and headers!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mocktail and Content-Type

ivan-ushakov opened this issue · comments

commented

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?

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?

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?

commented

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

@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.