WSDL / API Documentation Download Fails / Corrupt File

[clstopher]

Describe the bug The "Download SOAP Web Service API..." function doesn't download and unzip the Java documentation correctly. In the output log, I can see the following messages:

Going to download webservice api documentation from server: https://REALM-NUM.sandbox.us01.dx.commercecloud.salesforce.com/on/demandware.servlet/WFS/StudioWS/Sites/webrefgen2/calculator/calculator.api.zip Successfully downloaded web-service api documentation from server Error: too many length or distance symbols

I used the link from the log to download the file myself in Chrome and that was successful.

To Reproduce Steps to reproduce the behavior:

1. Upload a cartridge with a webreferences2 folder that contains a WSDL file. For my testing, I used this one as it seemed simple enough to rule out odd WSDL parsing or complicated namespacing issues: http://www.dneonline.com/calculator.asmx?wsdl
2. Execute a function in that cartridge that uses that WSDL file (eg, a line of code like var webRef = webreferences2.calculator;)
3. In vscode, right click on the WSDL file and click the "Download SOAP Web Service API..." option.
4. Choose a destination folder.
5. Try to unzip the downloaded file.

Expected behavior The zip file would be downloaded properly and optionally unzipped.

Desktop (please complete the following information):

• OS: Mac OS X Big Sur (11.6.3)
• VSCode version: 1.64.2 / f80445acd5a3dadef24aa209168452a3d97cc326
• The extension version: 1.4.25

Additional context I did a quick skim of the code to see if it was something I was doing wrong; Here are a few links that seemed relevant:

• https://github.com/SqrTT/prophet/blob/8f4a79ebbb50fd7cd5ec5ceeaed88381ab79262b/src/server/WebDav.ts#L260
• https://github.com/SqrTT/prophet/blob/8f4a79ebbb50fd7cd5ec5ceeaed88381ab79262b/src/server/WebDav.ts#L40-L43
• https://github.com/SqrTT/prophet/blob/8f4a79ebbb50fd7cd5ec5ceeaed88381ab79262b/src/server/WebDav.ts#L64

I suspect the problem is that string encoding is being applied to the downloaded data as it is received and joined, etc.

Some quick alternative thoughts - Maybe instead of downloading and unzipping the file, Prophet could just open a browser window to the generated URL and let a browser download it? Alternatively, I think the fix for the code would be to pass in your own response handler for binary files and write the bytes directly to disk as they are received rather than buffering them to a string array first.

[clstopher]

I just noticed that the code also does something with javadoc! I was happy enough just to have a bunch of .java files that told me what functions / types were exposed! So maybe my suggestion of just letting the browser download the file isn't enough - Or maybe 2 menu options could be exposed: 1) Download java files 2) Show Javadoc results if JDK is installed.