The .xlsx file uploaded on the server has size of 0 B

[intest]

The issue described initially here: https://stackoverflow.com/questions/67606009/how-to-upload-xlsx-file-successfully

The upload of .xlsx files not working properly in versions 1.0.0 and above. The file uploaded has a size of 0 B on the server.

* def storageId = 36bd8a5dd31

Given url 'http://example.com/'
* param storage = storageId
* multipart file file = { read: 'this:test.xlsx', filename: 'test.xlsx', MIMEType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'  }   
* header Content-Type = 'multipart/form-data' 
When method post
Then status 200

This is a code I'm using in my scenario. It works correctly in 0.9.6.

I hope that above description is enough to investigate and fix the problem.

[ptrthomas]

@intest I know it is hard but we need a working example, else there's nothing we can do: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue

[intest]

Yes, I know the page How-to-Submit, but I don't think it's necessary to do all that things to reproduce the issue. It's quite simple - upload worked in 0.9.6 and now it fails, I didn't change anything in my environment, beside the Karate version.
And closing the issue doesn't make the problem dissapear..

[staffier]

@intest -- Have you tried using "classpath:" instead of "this:"? Or adding the Excel file to the same folder as your feature file and getting rid of both prefaces? Or changing "test.xlsx" to "thisFileDoesNotExist.xlsx" to see what the end result is (does some ghost file with a size of 0 bytes get uploaded in this case, too)? Can you replicate the issue here?: https://encodable.com/uploaddemo

This could very well be an issue...but even if it is, there might be a simple work-around for it (without having to downgrade to 0.9.6). I ran into some cookie-related issues with v1.0.0 (fixed now) that were easily resolved by manually referencing a previously-generated Cookie header and plugging it into my subsequent requests, e.g. * def X = karate.prevRequest.headers['Cookie'], then using X as my Cookie header for the next request I ran...

[intest]

@staffier Thanks for a comment and suggestions. Yes, I have tried everything. I spent two working days trying millions times until I finally decided to check older Karate version :) The original file's name is something like "This Is a File.xlsx", so I changed the name for dozens variants, also changed "this:", "classpath:" etc. Nothing worked. I also tried with .csv file and the result was always the same - the uploaded file was 0B size.

It is also very difficult for me to prepare a working example to show the problem, as I use AWS S3 server for uploading the file, so I don't know how can I replace it in the example. I cannot provide my credentials :/

[ptrthomas]

@intest see if this makes any difference: #1579

[intest]

@ptrthomas is there any chance to fix it, please...? I tried literally everything and didn't find a working solution :(
With Karate 0.9.6 I have no problem with uploading files, but with 1.0.0 and up my files always has 0 B size on the server :(
It's really annoying and a bunch of my tests doesn't work due to that issue..

I don't know what details can I provide, but I'm using exactly the same configuration, server etc. in both cases (0.9.6 and latest versions), so there are no other differences.

Additionally I have a question (if this is an issue and new ticket is needed then I create one):
When I upload a csv file it is being converted to json, so I found in docs that I can use karate.readAsString(filename). And it works with 1.1.0.RC2, but file still has 0 B size.
But with 0.9.6 I'm getting:

* multipart file file = { karate.readAsString('this:data.csv'), filename: 'data.csv', MIMEType: 'text/csv' }
0
my_feature_file.feature:34 - mutipart file json should have a value for 'read' or 'value'

Was that function readAsString introduced in newest Karate version than 0.9.6?

PS. Alternativelly I do:
* multipart file file = { read: 'this:data.txt', filename: 'data.csv', MIMEType: 'text/csv' }
and it's fine, but still...

[ptrthomas]

@intest I added a test and it works fine, refer this file: https://github.com/intuit/karate/blob/a41bf767f8af423791591bb978d894a2261676a0/karate-core/src/test/java/com/intuit/karate/core/mock/upload.feature

I think the mistake you have been making all along is this MIMEType, there's no such thing in karate. please refer to the docs.

[intest]

@ptrthomas Thank you for testing that, but unfortunatelly it still doesn't work for me.
The example I put above is one of ~50 other tries I've done... I tried literally everything, like f.e.:

* multipart file file = { read: 'this:fink.xlsx', filename: 'fink.xlsx' }
* multipart file myFile = { read: 'this:fink.xlsx', filename: 'fink.xlsx', contentType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' }
* multipart file myFile = { read: 'fink.xlsx', filename: 'fink.xlsx', contentType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' }

and I can't remember the other dozens of examples... But it doesn't matter, because the result is always the same. File is uploaded successfully with Karate 0.9.6, and with Karate 1.0.0 and above the file has 0 B size:

The only hint I can make: I use * param storageId = storageId and two others in the request (and I need to in my test). Maybe this is some idea...

[ptrthomas]

@intest I have an example that works, so now it is completely up to you. we'll release 1.1.0.RC3 in a day or two, but you can try the developer guide to see if the latest version in develop is any better: https://github.com/intuit/karate/wiki/Developer-Guide

another thing I would try is force a contentType of contentType: 'application/octet-stream' just to see if it works.

the mock for the example I linked to above is super-simple. here it is below, so you can experiment with that and run your own server - and you should be able to create a fresh, stand-alone example of the whole dang flow in a few minutes (refer https://github.com/intuit/karate/wiki/ZIP-Release#api-mocks)

Feature:

Scenario: pathMatches('/upload')
* def filePart = requestParts['myFile'][0]
* def response = filePart

and the test is:

Feature:

Scenario:
* url 'http://localhost:8080'
* path 'upload'
* multipart file myFile = { read: 'test.xlsx', filename: 'my-file.xlsx', contentType: 'text/csv' }
* method post
* status 200
* match response == { charset: 'UTF-8', filename: 'my-file.xlsx', transferEncoding: 'binary', name: 'myFile', contentType: 'text/csv', value: '#ignore' }

all the very best.

[intest]

Hi @ptrthomas . I appreciate your help, but after another dozens tries, it still doesn't work for me.
What's more, when I use contentType: 'text/csv' I'm getting:

* multipart file file = {read: 'fink.xlsx', filename: 'fink.xlsx', contentType: 'text/csv' }
java.lang.NullPointerException

It doesn't occur with others content types, like 'application/octet-stream' and it doesn't occur with Karate 0.9.6 (only with 1.0.0 and above). Really strange...

[ptrthomas]

indeed very strange !

[intest]

@ptrthomas Just fyi: with 1.1.0.RC3 'text/csv' works, I mean there is no NullPointerException anymore, but the main problem remains - 0 B size. I'm giving up ;D

[intest]

And just as a prove, that with 0.9.6 the upload works :)
( And multipart file file = {read: 'fink.xlsx', filename: 'fink.xlsx', contentType: 'text/csv' } )

Nothing else changed in my code or/and environment.

What's been changed in Karate between 0.9.6 and 1.0.0? Some external libraries, anything I could check..?

[ptrthomas]

@intest here is the diff between 0.9.6 and 1.0 I'm sure your detective skills will find the culprit in no time: v0.9.6...v1.0.0

[intest]

Thanks, but.. why so sarcastic..? I'm trying to find a solution. And to help, cause maybe not only me have this problem (or maybe only me..?)

[ptrthomas]

@intest sorry, since you were so confident that you proved a point above and that nothing changed etc :) just ignore me please

[intest]

Heh.. Yes, I did no change in any character of my code. Just switched between Karate versions :) I can be confident in that point.
Do you suspect me to sabotage? ;)

[ptrthomas]

@intest I believe you ;)

okay, just want to make it clear I've tried every thing possible to help you. multiple people asked you to submit at least a cURL snippet but it has been ignored.

if we can't get a way to replicate, it ain't an issue. it may sound harsh to you - but that's how it is.
I went out of my way to give you way to run a local upload server mock. that's been ignored as well.
and yes, given that no one else has reported this issue - it is quite likely that you are doing something unique.

can it be a change in karate behavior from 0.9.6 to 1.0 oh ABSO-fing-LUTELY.
do I know what it is. NO. is there a way to find out ? YES. it is up to you now.

[intest]

OK, let's cool the atmosphere. I really appreciate every kind of help, but honestly - generating a cURL snippet from another tool doesn't make sense in this case, since it worked in 0.9.6, so it's not an issue with the request I'm sending.
I admit that I didn't try with local/mock server, so I will do that and let you know about the result.

Sorry for bothering, but this issue is so frustrating and enigmatic.. :/

[ptrthomas]

@intest

generating a cURL snippet from another tool doesn't make sense in this case, since it worked in 0.9.6

lol, you raised the issue on stack-overflow saying that "it works in P0stman" and now this. how convenient. now I strongly suspect whether it works in P0stman or not. prove it :)

and of course you completely missed the point that the cURL helps other developers figure out what's unique about the request.

I'm locking this thread as "too heated". you can open a new one if needed, but it does sound like tools like P0stman are simpler and possibly a better fit for you. peace.