Skip to content

Reimplemented http_client using the ocurl library#127

Closed
carlonluca wants to merge 20 commits into
ygrek:masterfrom
carlonluca:https-fix
Closed

Reimplemented http_client using the ocurl library#127
carlonluca wants to merge 20 commits into
ygrek:masterfrom
carlonluca:https-fix

Conversation

@carlonluca

Copy link
Copy Markdown
Contributor

This commit reimplements the http_client module by using the ocurl library. This should add support for the https protocol.

@carlonluca

Copy link
Copy Markdown
Contributor Author

The implementation is still a work in progress, which is the reason why it is a bit too verbose. This is the first patch needed to fix #119 and #41. Comments are welcome.

@ygrek ygrek left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cursory review

Comment thread src/utils/net/http_client.ml Outdated
Comment thread config/Makefile.in Outdated
This commit reimplements the http_client module by using the ocurl
library. This should add support for the https protocol.

@ygrek ygrek left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, getting there
didn't review http_client.ml completely yet

Comment thread config/Makefile.in Outdated
Comment thread config/configure.in Outdated
Comment thread src/utils/net/http_client.ml Outdated

@xOneca xOneca left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to test this PR, but found some issues with the configure script.

Also made a suggestion to use the app name instead of the library name as User-Agent.

Now that compiles for me, I'll be testing it some time...

Comment thread config/configure.in Outdated
Comment thread config/configure.in Outdated
Comment thread config/configure.in
Comment thread config/configure

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this file do not match configure.in and will be overwritten by running autoconf. Specially important with the two new exit 1 that only exist here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why there are both. Maybe I'm supposed to generate the configure script and version it.

Comment thread config/configure.in Outdated
Comment thread config/configure.in
Comment thread config/Makefile.in

ICONS_CMXA=icons.cmxa

LIBS_opt += $(OCAMLLIB)/threads/threads.cmxa

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't be searched using ocamlfind, as is done with Curl?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know if there is a way to do it with ocamlfind alone:

# ocamlfind query threads
/usr/lib/ocaml

let def_user_agent =
let ua = Curl.version_info () in
let v = ua.Curl.version in
Printf.sprintf "curl/%s" v

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not identify the real application making the request? I would use MLDonkey/x.y.z or, if you prefer, MLDonkey/x.y.z curl/a.b.c. (See example in RFC 9110 § User-Agent)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TcpBufferedSocket.connect is using the first form for the proxy mode:

Printf.bprintf buf "User-Agent: MLdonkey/%s\n" Autoconf.current_version;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, there is a global option, used in many places:

let user_agent = define_option current_section ["user_agent"]
"User agent string (default = \"default\")"
string_option "default"

The value default uses MLDonkey/x.y.z format.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My patch should only switch the default from wget to curl. Callers already pass in the proper user agent.

@xOneca

xOneca commented Jun 23, 2025

Copy link
Copy Markdown

Also, I suppose GitHub workflow now needs libcurl-ocaml-dev installed too.

@xOneca xOneca left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @carlonluca,

Thanks for your updates!

I think I didn't explain the changes correctly, so here is a second review round for the Autoconf files.. 😄

Comment thread config/configure.in Outdated
Comment thread config/configure.in Outdated
Comment thread config/configure.in Outdated
Comment thread config/configure.in
Comment thread config/configure.in Outdated
Comment thread config/configure.in
Comment thread config/configure.in
@xOneca

xOneca commented Jun 25, 2025

Copy link
Copy Markdown

So, here I was thinking this was the only HTTP client implementation in MLDonkey, and in fact there are two! 😕

As I can see, the HTTP client in this PR is used only for:

  • WebInfos: tested both HTTP and HTTPS and works perfectly! 💯
  • Torrent trackers: could not find (yet) an HTTPS tracker, but HTTP works!

And dllink <url> also seems to use it (to no avail):

2025/06/25 16:45:57 [dCmd] execute command "dllink" "https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-12.11.0-amd64-netinst.iso.torrent"
2025/06/25 16:45:57 [HTTPcl] whead
2025/06/25 16:45:57 [HTTPcl] wget_string https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-12.11.0-amd64-netinst.iso.torrent
2025/06/25 16:45:58 [HTTPcl] HTTP success: https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-12.11.0-amd64-netinst.iso.torrent
2025/06/25 16:45:58 [BT] Not_found and url has non valid torrent extension: Date: Wed, 25 Jun 2025 16:45:58 GMT
Server: Apache/2.4.63 (Unix)
Last-Modified: Sat, 17 May 2025 11:47:38 GMT
Accept-Ranges: bytes
Content-Length: 54073
Age: 3184
Content-Type: application/x-bittorrent

It seems to download the torrent file, but then fails to detect that it is, in fact, a torrent file and the torrent is not enqueued for download. Tried both HTTP and HTTPS. 😞

Seems to be parsing headers as the name of the file? Maybe searching the name in the headers? 🤔

@carlonluca

carlonluca commented Jun 25, 2025

Copy link
Copy Markdown
Contributor Author

Hello,
yes, there are two different implementations of HTTP client. I discussed this point somewhere in the issues. From what I can remember, one implementation is only used for FileTP, and I said I won't work on that. I think I tested HTTPS trackers with an Ubuntu torrent, and it worked.

Much time has passed since I sent this PR, but I think torrent files are downloaded with the new implementation. In fact, I tested your link and also this one https://releases.ubuntu.com/25.04/ubuntu-25.04-desktop-amd64.iso.torrent. Both started immediately.

I remember I had to fix multiple bugs related to this problem. Can you confirm you are not able to download that torrent you provided?

@carlonluca

carlonluca commented Jun 25, 2025

Copy link
Copy Markdown
Contributor Author

Ok, I suspect I missed some commits in this PR. I probably restricted this PR to the HTTPS client itself. This may fix the issue you are seeing: carlonluca/mldonkey@d4592d7. My fork includes this, but I can't find it in this PR.

Unfortunately my fork has diverged quite a bit. I'll have to go through everything again and see if something else is missing.

In the meantime, thanks for your review. I'll work on what is missing.

@carlonluca

Copy link
Copy Markdown
Contributor Author

Ok, sorry, it seems you may need more than this PR to get proper HTTPS for bittorrent support. This is what I have in my fork: https://github.com/carlonluca/mldonkey/commits/dev/. You probably want to use that if you want bittorrent to work properly. This PR is strictly for the client.

carlonluca and others added 10 commits June 26, 2025 19:06
Co-authored-by: xOneca <xoneca@gmail.com>
Co-authored-by: xOneca <xoneca@gmail.com>
Co-authored-by: xOneca <xoneca@gmail.com>
Co-authored-by: xOneca <xoneca@gmail.com>
Co-authored-by: xOneca <xoneca@gmail.com>
Co-authored-by: xOneca <xoneca@gmail.com>
@carlonluca

Copy link
Copy Markdown
Contributor Author

I moved my fork to dune and ocaml5, making this PR pretty outdated (more info here: https://bugfreeblog.duckdns.org/2025/08/mldonkey-ocaml5.html). I will not update this further so I close it.

@carlonluca carlonluca closed this Aug 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants