Upload the same data on `/bytes` returns different reference IDs

[filoozom]

Summary

When uploading data on /bytes, I get different reference values. On /files, I get the same.

Steps to reproduce

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"e3acfc98d082a63ee3d69fc2e9e35b843fe26d946a5fa42a90931d5d01ef9454"}

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"1489b9b4ab1323e28905c51341d4a5ed294100224e9e95b96f8a08b8d21fe5fd"}

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"62fcceed6ae805d07868723a0e27a425e59e672ceb5c452e62d4adcfc891ce1f"}

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"9569ee403610f37fd8c7d65bd77a9e8a07d7feecf0902d6b0005fcc0982af7b1"}

Expected behavior

Getting the same reference, like on POST /files

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"5ba4f584015e669029351f3eabb99e815d151880dbd78bf4e4c230f3cacf5f5e"}

$ curl -F file=@1G-zero.dat http://localhost:1633/bytes
{"reference":"5ba4f584015e669029351f3eabb99e815d151880dbd78bf4e4c230f3cacf5f5e"}

Actual behavior

Different IDs are returned.

[Eknir]

Thanks for reporting. We are looking into this!

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[acud]

@filoozom is this still a thing?

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[acud]

@filoozom is this still a thing?

[filoozom]

@filoozom is this still a thing?

I honestly don't know, I'll try to test this and will keep you updated.

[anatollupacescu]

@agazso will double check if this is still relevant.

[agazso]

This is still an issue, the only difference is in the way of reproduction. Since then the postage stamp header is required for uploading:

% curl -F file=@10M http://localhost:1633/bytes -H "Swarm-Postage-Batch-Id: c3730dbd0453f3c8547a0c1daa659e09f45b63f8ca312189357dd347efe02cc0"
{"reference":"6e337131b27db1c7a9db203bdd60a3fe626adf3f2b2633dd4d5b3b73d4e47d43"}

% curl -F file=@10M http://localhost:1633/bytes -H "Swarm-Postage-Batch-Id: c3730dbd0453f3c8547a0c1daa659e09f45b63f8ca312189357dd347efe02cc0"
{"reference":"65d980a8dea55bfe057dc4d26687deb03129a252ca885552662dd040928d6b9c"}

% curl -F file=@10M http://localhost:1633/bytes -H "Swarm-Postage-Batch-Id: c3730dbd0453f3c8547a0c1daa659e09f45b63f8ca312189357dd347efe02cc0"
{"reference":"543074a06026f44cc57c3d2e0fac570faa8ceaf73ce7572a1b39b01a96166e7e"}

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[acud]

@agazso you're using -F which is a multipart upload which is not supported on the /bytes endpoint. The problem is that because of the excess multipart data (and the random multipart separator that gets added into the request) you're essentially getting a different content addressed hash because the data indeed changes every time. If you upload using --data-binary @<filename> the problem goes away. I'm uploading a screenshot for illustration. I would suggest to either close this issue or at least amend it so that we just deny/accept multipart support explicitly for this endpoint.

[agazso]

In that case I would suggest to return 400 Bad Request error if multipart upload is requested on the /bytes endpoint.