Request header content-type should be application/x-bittorrent

[JanGross]

When trying to upload a new torrent, the request gets sent as content-type multipart/form-data and thus the API throws

Request header content-type should be application/x-bittorrent

I tried using both Chrome and Firefox against the demo instance.
Request headers for reference (some parts omitted):

POST /api/v1/torrent/upload HTTP/2
Host: index.torrust-demo.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: */*
Accept-Encoding: gzip, deflate, br
Referer: http://index.torrust-demo.com/
Content-Type: multipart/form-data; boundary=---------------------------108118935725644999701078262824
Content-Length: 51548

Request body for reference

-----------------------------108118935725644999701078262824
Content-Disposition: form-data; name="title"

Test Debian
-----------------------------108118935725644999701078262824
Content-Disposition: form-data; name="description"

Test description
-----------------------------108118935725644999701078262824
Content-Disposition: form-data; name="category"

software
-----------------------------108118935725644999701078262824
Content-Disposition: form-data; name="tags"

[1]
-----------------------------108118935725644999701078262824
Content-Disposition: form-data; name="torrent"; filename="debian-12.5.0-amd64-netinst.iso.torrent"
Content-Type: application/octet-stream

d8:announce41:http://bttracker.debian.org:6969/announce7:comment35:"Debian CD from cdimage.debian.org"10:created by13:mktorrent 1.113:creation datei1707570148e4:infod6:lengthi659554304e4:name31:debian-12.5.0-amd64-netinst.iso12:piece lengthi262144e6:pieces50320:[.. remaining binary content]

As a test file I used the amd64 Debian CD ISO .torrent from https://www.debian.org/CD/torrent-cd/

[josecelano]

Hi @JanGross thank you for opening the issue. I've just tried with both Chrome and Firefox and I can't reproduce the problem.

The uploaded torrent:

https://index.torrust-demo.com/torrent/2b66980093bc11806fab50cb3cb41835b95a0362/debian

The torrent I've used:

debian-12.5.0-amd64-netinst.iso.zip

• Chrome: Version 121.0.6167.184 (Official Build) (64-bit)
• Firefox: 122.0.1 (64-bit)

For some reason your browser is using Content-Type: application/octet-stream instead of Content-Type: application/x-bittorrent.

This is what I send using my browser:

------WebKitFormBoundaryE39daJzrw41gMMES
Content-Disposition: form-data; name="title"

debian
------WebKitFormBoundaryE39daJzrw41gMMES
Content-Disposition: form-data; name="description"

debian
------WebKitFormBoundaryE39daJzrw41gMMES
Content-Disposition: form-data; name="category"

software
------WebKitFormBoundaryE39daJzrw41gMMES
Content-Disposition: form-data; name="tags"

[]
------WebKitFormBoundaryE39daJzrw41gMMES
Content-Disposition: form-data; name="torrent"; filename="debian-12.5.0-amd64-netinst.iso.torrent"
Content-Type: application/x-bittorrent


------WebKitFormBoundaryE39daJzrw41gMMES--

Anyway, I guess I think we could accept also that generic binary mime type here. I will change it so you can try it. I guess it's not a problem to accept also that type because it will fail later if it can't parse the torrent file.

Have you tried with a different torrent file? I would like to confirm that the problem is the browser version (or something else) but not the torrent file you are using.

[JanGross]

Seems like I need to do some further debugging on my end...
I just tried again on a different Windows Machine and it worked just fine using both Chrome 121.0.6167.185 and latest stable 122.0.6261.5.

Very weird. 🤔 I'll take a closer look at my other machine tomorrow to see if I can figure out what's causing the different headers.
And yes, I did try torrents from entirely different sources as well.

https://gist.github.com/JanGross/3b86e154b2df109354beb4478b0b8861

[josecelano]

Hi @JanGross I'm trying to find out why. This is a ChatGPT response:

The variation in MIME type (Content-Type: application/octet-stream vs. Content-Type: application/x-bittorrent) for a torrent file when uploading via an HTTP POST request can be attributed to a few factors:

1. Client-Side MIME Type Determination: The MIME type is often determined by the client (e.g., web browser, HTTP client library) that is performing the upload. Different clients may have different ways of identifying the MIME type of a file. Some clients might simply tag all binary files as application/octet-stream, which is a generic MIME type for binary data, while others might specifically recognize the file as a torrent and assign the application/x-bittorrent MIME type.

2. File Extension and System Associations: The MIME type can be inferred from the file extension. If the system or application uploading the file has a specific association for .torrent files, it might set the MIME type to application/x-bittorrent. In the absence of such association, it might fall back to the generic application/octet-stream.

3. Server-Side Interpretation: In some cases, the server receiving the file might interpret or even alter the MIME type based on its own configuration or processing logic.

4. MIME Type Databases: Different systems and applications use MIME type databases (like /etc/mime.types on Unix systems) to map file extensions to MIME types. Variations in these databases across different systems can lead to differences in the MIME type assigned to the same file.

5. Manual Overrides: In some client implementations, the MIME type can be manually set during the upload process. If an application or user explicitly sets the MIME type, it will be used instead of any auto-detected value.

6. Updates in Standards or Applications: Over time, the standards or the way applications handle MIME types can change. What might be recognized as one MIME type in an older application or standard might be recognized differently in a more recent version.

To ensure consistency, if you have control over the client-side implementation, you might want to explicitly set the MIME type to the desired value when performing the file upload.

Anyway, as I said I think there is no problem with accepting also the type application/octet-stream. I will open a PR to accept also that type.

[JanGross]

I figured it out.
The first machine never had any torrent client installed and no filetype association for .torrent set in Windows.
The mime-type was set correctly after I installed a torrent client (qBittorrent) AND associated the .torrent extension.
(and also restarted chrome)

Sorry for the confusion and thanks for the support👍🏼

[josecelano]

I figured it out. The first machine never had any torrent client installed and no filetype association for .torrent set in Windows. The mime-type was set correctly after I installed a torrent client (qBittorrent) AND associated the .torrent extension. (and also restarted chrome)

Sorry for the confusion and thanks for the support👍🏼

@JanGross cool! I'm going to add the other type anyway because I think other people could have the same problem.

[josecelano]

Closed via torrust/torrust-index#491