I just spent way too much time figuring out why I was not receiving a notifo. I sent a request with Host: api.notifo.com:443 and got back the following 200 response (but the notifo was never sent)
HTTP/1.1 200 OK
Date: Fri, 21 Jan 2011 18:04:32 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html
When I forced my HTTP client to omit the port number in the Host header the service worked as expected. Sending the port number is perfectly valid per RFC2616, so I hope this is just an oversight. I'd also hope for a non-2xx code in the event that the request is going to be dropped. Cheers,
Adam
Hi Chad, sorry for the long delay. I'm using https://github.com/cmullaparthi/ibrowse to make the request in production.
If you turn on the verbose flag in your curl command you should see that curl actually suppresses the port number in the Host header when you make a request to ports 80 and 443, even if you explicitly add it to the URL. On the other hand you can craft the Host header yourself, and in this case the request will fail. For example:
curl -v https://cloudant:****@api.notifo.com/v1/send_notification -d 'to=kocolosk&message=test' -H 'Host: api.notifo.com:443'
I have just encountered the same problem attempting to send notifications from within Logitech Media Server (aka SlimServer, SqueezeCenter or Squeezebox Server). Unfortunately there doesn't appear to be an easy way to prevent its Slim::Networking::SimpleAsyncHTTP or Slim::Networking::Async::HTTP library from adding the port number to the Host header.
Are there any plans to modify the Notifo server to cope with the port number being specified in the Host header?
It looks like you're new here. If you want to get involved, click one of these buttons!