I have been investigating Actions lately. From what I can observe it seems that URLs used has some constraints to them, that I have not been able to find in any documentation or description:
A) HTTP is not supported, only HTTPS.
B) Non-standard ports are not supported. I.e. since only HTTPS is supported only 443 can be used.
C) IPv6 is not supported. I have tried to use domain names without A records, but with AAAA records, which works well using curl, but it seems Actions can not talk to them.
My questions are:
- Is my understanding correct?
- Is there some documentation on Actions describing these constraints?
- Are they considered features or bugs?
- Can I file bug reports or feature requests somewhere for adding support for these use cases?
I am not asking how I can circumvent these constraints, I know well how to do that, so please refrain from comments like “HTTP is unsafe”, “you can use a reverse proxy”, etc. That is totally beside the point.
/Niklas
I didn’t think these would be classified either as bugs or features, but rather simply as limitations to the system as built.
Another limitation is the lack of support for query string API keys.
Workarounds are easy enough, but I agree it would be better if they weren’t needed.
I had a meeting about GPTs some time ago with one of the ChatGPT product managers, who invites me to share any other ideas for improving the platform.
If you want me to, I will roll these (and any other limitations you can identify) into the ones I already have and send them along.
If possible, it would be useful if you could include specific use cases which necessitate adding the features.
For example, my argument for including query string API keys is that they are extremely common in many commercial API products (particularly Google), enabling builders to use query string API keys opens up a world of additional actions for builders unwilling or unable to use or setup an API gateway.
As for http vs https, I’m not sure but I suspect there may be some issues related to data privacy and security which may prevent them from allowing http actions.
Oh usecases are pretty simple to come up with, and is basically the same as yours. There exists services which are either:
- HTTP only (however quickly disappearing, although there are legitimate uses, e.g. debugging traffic patterns from the side, or reducing global warmth by evading encryption on non-sensitive data
). I confess this is not important, but it wasted my time when wanting to debug GPT actions traffic.
- HTTPS but hosted on other than port 443. For service providers with limited IPv4 address space, this is the way to provide more services, without introducing performance degrading reverse-proxies, which also often can be SPOFs.
- HTTPS but only in IPv6 space. There are IPv6 only network attachments out there. Of course that to can be solved with relays, but as always: performance-degrading, and added complexity.
There are reason these options exist on the Internet.
Now I cannot enumerate services that requires these, but i think that is beside the point. It’s more that the GPT actions should be as liberal as possible as to what services they could support. The Internet standards allows for such to exist, and therefore people will want them to work.
Many thanks for your offer to include these limitations in your discussions!
/Niklas
I will include them, but if you had specific use cases that would be better.