add HTTPS support

[mingfang]

Currently hardcoded to HTTP only.

incubator-hugegraph-ai/hugegraph-python-client/src/pyhugegraph/utils/huge_requests.py

Line 112 in ca28faf

url = f"http://{self._cfg.ip}:{self._cfg.port}/"

[imbajin]

@mingfang Thanks for your suggestion, we can indeed be compatible with it, but is there a more user-friendly way where users don't have to prefix it with HTTPS? Welcome your suggestions or improvements

[chiruu12]

@imbajin sir maybe we can allow the user to set it themselves?
like a setting of sorts, we can keep this as default value while allowing the devs to customize it however they want to?

[imbajin]

sir maybe we can allow the user to set it themselves?
like a setting of sorts, we can keep this as default value while allowing the devs to customize it however they want to?

@chiruu12 OK, a simple idea is to determine whether the first character of the IP/URI_PREFIX param is a number:

• If it is, it defaults to the HTTP protocol.
• If not, only the HTTP and HTTPS string prefixes are supported for filling in.

This way, ordinary users can directly write the IP and maintain compatibility with HTTPS/HTTP

[chiruu12]

@chiruu12 OK, a simple idea is to determine whether the first character of the IP/URI_PREFIX param is a number:

• If it is, it defaults to the HTTP protocol.
• If not, only the HTTP and HTTPS string prefixes are supported for filling in.

@imbajin sir this can be an approach, but we can make it better by using regex filter instead just checking the first character can cause problem as some website like 365x.ai will be having the first character as a number but it is a URI not IP I found a regex pattern for IPv4 Addresses which is

^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$

using this we can assure that we are categorizing the IP/URI properly and this approach would allow users to input addresses without worrying about the correct protocol prefix, enhancing usability. What are your thoughts on this solution?

[imbajin]

using this we can assure that we are categorizing the IP/URI properly and this approach would allow users to input addresses without worrying about the correct protocol prefix, enhancing usability. What are your thoughts on this solution?

@chiruu12 It reminds me that we don't need to distinguish between domain names and IP.

Some user input like:

1. 10.xx.xx.xx
2. abcd.org
3. https://whoami.org

We just need to construct a valid URI, and the logic can be simplified as checking whether the IP field prefix is https://:

• If it is, adjust the URI to the HTTPS prefix.
• Otherwise, all IP/domain names filled in directly will be passed in via HTTP

Seems no need to use regex pattern?