4 ms·

Hey, thanks, but it's not a bug :) that's protocol independent URL, it works on HTTP, HTTPS, relative to what your website is running on.

sillysaurus3 9y ago
The primary purpose of your app is to paste some JSON then send someone a URL to access it, right? If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature. It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL. I admit I might be missing something obvious, though.
- mr_ali3n 9y ago
  The primary purpose of the app is to provide free storage and an endpoint to access it in an app. I've also provided a VIEW link beneath the access URL to view it in the browser. If I hard code https:// https:// in front of the access URL, it might fail on non-https URLs and vice versa. Still, I think your concern is legit, will look into it and try to make it more flexible. Thanks for the suggestion bud. Appreciated.
  - sillysaurus3 9y ago
    Ah, got it. Nah, you're right, it's obviously meant to be used from within apps, not manually sent to someone else. Just a late-night derp. I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial. (I missed the About link https://jsonbin.io/about https://jsonbin.io/about at the bottom, which explains all this.)
  - hdhzy 9y ago
    Yeah it also struck me as something weird and I know about using //. Maybe prepend http/https based on the current page's protocol? So that URL looks like a URL. By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
  - adnanh 9y ago
    it's perfectly okay to load https content on the http urls, just not vice versa

sillysaurus3 9y ago

The primary purpose of your app is to paste some JSON then send someone a URL to access it, right? If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature. It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL. I admit I might be missing something obvious, though.

mr_ali3n 9y ago
The primary purpose of the app is to provide free storage and an endpoint to access it in an app. I've also provided a VIEW link beneath the access URL to view it in the browser. If I hard code https:// https:// in front of the access URL, it might fail on non-https URLs and vice versa. Still, I think your concern is legit, will look into it and try to make it more flexible. Thanks for the suggestion bud. Appreciated.
- sillysaurus3 9y ago
  Ah, got it. Nah, you're right, it's obviously meant to be used from within apps, not manually sent to someone else. Just a late-night derp. I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial. (I missed the About link https://jsonbin.io/about https://jsonbin.io/about at the bottom, which explains all this.)
- hdhzy 9y ago
  Yeah it also struck me as something weird and I know about using //. Maybe prepend http/https based on the current page's protocol? So that URL looks like a URL. By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
- adnanh 9y ago
  it's perfectly okay to load https content on the http urls, just not vice versa