Welcome to the support forum: wave: I’m going to try and support you in solving this issue you’re running into. This is just a note to let you know that I’m on it, and will come back to you as soon as I have additional information for you
After spending some time trying to determine what could be the problem in your case, I’m afraid I only have pointers to offer. I’m not familiar with Fiddler, and it being a paid application requiring registration, I can’t run it myself.
However, the specific error you see are related to parsing the .har file that was generated. Namely, the har-to-k6 tool opened your file, and tried to interpret it, but failed immediately (that’s what the Unexpected JSON token at position 0). HAR being a specification for a JSON-based file format recording HTTP interactions, my first hunch goes to thinking that maybe either Fiddler generated a file that har-to-k6 is unable to parse, or one that for some reason turns out to be written using an encoding that’s incompatible with har-to-k6.
However, all I can offer are suppositions. Without having access to your specific har file, it would be hard to find out what exactly doesn’t work out. If you’re comfortable with that, I would be happy to take a look at your har file (anonymized): if you would send it to me privately (you can do that by clicking on my profile, and then “message”).
Let me know if that’s any help
PS: you might have found them already, but as a reference, the har-to-k6 project has a number of examples, which could help outline the issue on your side?
I think I got to the bottom of the issue. It occurs that the problem you’re encountering has already been met in the past, and is already known by the team who maintains har-to-k6. A Pull Request on the project is opened, and although I have no visibility on when a fix is planned to be merged, the issue is known and on our radar.
It happens that Fiddler generates har files that use a Byte order mark. In a nutshell, the file contains a magic number byte, indicating that the file is encoded in Unicode, with a specific charset, and gives information as to the endianness (the order in which the file’s bytes should be read) of the data in the file.
Because I cannot tell when the fix will be merged, here is a command you can apply to any file that has been generated by Fiddler, which should hopefully solve your issue:
sed '1s/^\xEF\xBB\xBF//' < my-original-file-with-bom.har > my-original-file-without-bom.har
Running this on a file will effectively drop its byte order mark. I’ve tested it with the script you’ve sent me, and it seems to have solved the unexpected JSON token at position 0 issue you’ve been experiencing.
Let me know if that solves things for you, and if I can assist you with anything else
It looks like you won’t have to use sed on Windows, as har-to-k6 v0.13.0 has been released meanwhile, and should be solving the issue you’ve been encountering. Could you try it and let me know if that’s indeed the case?