If you save an image in bubble, the url is returned as “//s3…”
Why isn’t it “https://s3…”?
1 Like
I have no idea why they only store the path part and not the protocol. But that’s what happens.
This tripped me up for the umpteenth time a few days ago. See this thread:
Read the whole thing down to where @mishav chimes in and I reply. The “solution” marked in this thread works, but Misha points out that it does seem incorrect the way Bubble is handling this.
I’ve got some other more urgent bugs filed right now so I’m not keen to report this, but I don’t understand it either. Just know that, if you want to link out to one of those files you CAN (do it the way I explain in the thread). But if you want to write out the URL as text or something, you’ll have to add the “https:” part yourself.
This might also be an issue if you’re passing such an URL to an external API or something.
Anyway, I’m not sure if it’s intentional that Bubble just stores the path, but clearly the NAME for the field is misleading. The “URL” to the s3 file is not a fully-qualified URL, but is in fact a PATH.
This doesn’t make a lot of sense because I think s3 only allows reference via https: (not http:) so I’m baffled by this if it’s NOT a bug. #shrug
While clicking on the s3 file’s url within a link element directs to the image successfully, is the issue that file’s url displays path and doesn’t include ‘https’?
Pretty much. The question is: Why is it stored this way? (Is there some reason, or is it a bug?)
I’ve run into this in other contexts: For example, I have an API that sends me back a file. The file gets stored in s3. I then do things with the file like create a Rebrandly alias for it. When I ping Rebrandly’s API, I have to send the Rebrandly API an expression like:
https:my_file_thing's file's URL
when it seems like it should just be: my_file_thing's file's URL
Of course at this point, to change that behavior would be a breaking change.
As Misha pointed out in the other thread, the link element works because one’s browser expands the path correctly:
But this is counter to how one would do URLs in one’s app or how most any API (that accepts a URL argument or whatnot) would have you specify a URL. On the same page I snipped above, for example, I show the URL that is the source of the PDF thing, that URL was sent to an external API as a fully-qualified URL and I store it in my database as a fully qualified URL. And the link I create to it is of course a fully-qualified URL:
It’s just… like… why would you do this any other way? 
At a minimum, the docs and the label on s3 URLs are not correct. This thing IS NOT the file’s URL. It is the file’s PATH.
A non-breaking fix would be to change the NAME of file's URL field to file's path and make a new field for file's URL that is ACTUALLY the fully-qualified URL.
4 Likes
Correct. The image url may load in your browser, but if you fetch the it from an API, it poses a problem. You have to first prepend the url with https.
With “https:” 
Just wanted to add that bubble not saving images with https: has been a hell for Dropsource users.
If you go to their forum and search https you will see a lot of discussions on it like this thread.
So if you’re developing in Dropsource and using bubble as backend, you always have to create a workflow in bubble to prepend the https: or you have to create an action in dropsource to do that before you could use bubble images.
I still don’t know the reason why bubble does it this way.
2 Likes
It’s derpy in the extreme. Somebody should file a formal bug report as I can’t see any reason for this either. (But I got my own bugs, yo, and Neerja is tired of hearing from me. 
)
I’m not sure if we can classify this as a bug. Because i’m very sure it is by design.
Plus bubble is very aware of it.
I want to believe there is a good reason they have the current setup.
I’ve brought this up before so I can only hope they add it for us.
Do not be sure about that. They should just answer the damn question (why). To get that answer still requires a bug report.
Thanks all. Will review the feature request with devs and post back.
@seanhoots yup, submit your own bug report 