[benoliver999]

Funny, I was just looking for an alternative to pushover that doesn't use google services last week. Tested this and it worked quite well.

I actually wound up just using an SMS gateway provider with a simple API you can just fire a get request to.

[StavrosK]

I had exactly the same problem, and ended up using Signal. I like it more than normal push notifications because you can reply and have a full chatbot running.

I liked it so much that I even wrote a small Python library for it: https://gitlab.com/stavros/pysignald/

[tuxxy]

That's pretty neat, but could you add an Open Source license to it? It's gonna make folks hesitant to use it.

[StavrosK]

Thanks for reminding me, I forgot to add the file. The license is actually MIT, as you can see on the PyPI page (https://pypi.org/project/pysignald/).

[callalex]

Sending a text message uses the GET verb? Yuck.

[verelo]

I get why that's "yuck" but if I'd hedge a bet...it's probably done because it's easier to make a GET than it is a POST or PUT request and the length of a text message will never exceed the query string uri length limits.

Not saying I disagree, but i don't know it changes a whole lot in this case.

[beager]

In this case maybe, but generally GET should be avoided for any creative/transactional action because many systems will replay/cache GET requests, assuming that they’re idempotent.

[verelo]

Yeah the caching issue is a great reason not to use a GET, i was more just suggesting if you're being lazy and pasting a request into a browser v's using a command line (which obviously you should) then it's easy to get going quickly to kick the tires.

[eridius]

If you really want to, you can in fact issue a POST with a query string and no body. It would admittedly be rather unusual.

Also, application/x-www-form-urlencoded bodies are literally identical to query strings anyway, so if you can construct a query string, you can easily construct a POST body using that Content-Type too.

[cortesoft]

How is a GET request easier? I assume you need to include authentication somehow, so it isn't like you are triggering it by typing the url in a browser.

[Groxx]

just to point out: there are no uri length limits. browsers typically have one (I haven't checked lately tho), but other tools generally don't (except by mistake / size-capped buffers).

[asddgsgsaxg]

Not sure why you believe this so strongly, but every single HTTP client impose some limit.

Modern browsers are typically around 100-200k limit, command line tools such as curl and wget also has their limits.

IE was famously limiting GET requests to about 2k bytes.

[Groxx]

the spec does not define a limit, and the widely varying implementation-specific limits are soft evidence of that.

even wget and curl are probably more limited by your CLI arg length limits than the bins themselves. e.g. I can craft a multi-megabyte GET request in a file and pass it to `curl -K` and it works just fine (I just did so to verify, a bit over 3MB. google complained a bit, but it responded). even if I screwed that up somehow / it silently truncated, I can absolutely do something with netcat and know it won't truncate.