I'm thinking this can be a toast when they set an HTTP URL.

Thats a good idea.  Actually it could try to resolve through PWS before setting the URL and warn if it would be filtered.

However, I think the intention of this bug was at the scanner level -- both are useful.

..re-reading Ani's message, I don't think that was his intention, I was wrong.

But I still think we could do both.  Maybe there is another bug for that..

Yep, it was at the filtering level, so I think Conley's suggestion would work well. Although, would we want to have some sort of more persistent UI in case developers miss the toast (perhaps immediately below the URL field on the config app)?

But separately, agree Michal, makes sense to do something at the scanner level too

> Actually it could try to resolve through PWS before setting the URL and warn if it would be filtered.

That's a good idea...if that's the case we should probably implement the switch to the production PWS first.

> I think the intention of this bug was at the scanner level

I recognize that, but I can think of anything that wouldn't be annoying to some degree...what exactly would we want?

We serve up a toast when you config a beacon to use a non-HTTPS URL.