I know that there are no blob urls only objects.
I made my own blob object for a video buffer and then I used it in a src of video tag which is something like blob://website.com/blablobbla . I opened this url in the browser it worked
when I opened the url of youtube video src (blob url) into a new tab it did't work but mine video src (blob url) worked
I want to know how can I do the same with my blob urls so that they only work in the src of the html video tag and give error or don't work in the external tab/window of the browsers.I just want to know the technology behind this and blob objects and their url properties.
The question seems somewhat vague to me, so here is what I interpret (also from the code in the fiddle-images in your question):
Blob
(image's binary data) through aXMLHttpRequest()
GET
-request (responseType = 'blob'
)Blob URL
withURL.createObjectURL()
in theURL Store
forXMLHttpRequest()
response
-object (theBlob
holding the binary data)Blob URL
-string assrc
for a image (and append the image to the document, thereby showing the image you just downloaded)Blob URL
-string I assume).In your comments you say:
It appears to me that you do not want the user to be able to view/download the blob when they copy the
Blob URL
-string (by examining the live source or simplyright-click-on-image>>Copy Imagelocation
) and paste it into a new tab/window (for which you give youtube as an example).But you are also talking about video's.
TL;DR: It seems your question/bounty might be mixing up 2 different types of URL returned by
window.URL.createObjectURL();
:Blob URL
referencing (objects that represent) 'raw local data' (like (Local-)File, Blob, etc.)For these you want to automatically (or programmatically) revoke the
Blob URL
from the browser'sURL Store
(which you could consider a simplified local webserver inside the browser, only available to that browser).var myBlobURL=window.URL.createObjectURL(object
, flag_oneTimeOnly);returns a re-usable
Blob URL
which can be revoked with:window.URL.revokeObjectURL(myBlobURL)
(adds theBlob URL
string to theRevocation List
).Note: there used to be a second argument
flag_oneTimeOnly
which used to revoke theBlob URL
automatically after it's first use, but that is currently no longer part of the spec! Also this flag often didn't work anyway (at least in firefox).var myBlobURL=window.URL.createFor(object);
returns a
Blob URL
that is automatically revoked after it's first use.Note: quite some browsers were 'late' to implement this one.
MediaSource object URL
referencing a special MediaSource ObjectThese URL's are
src
of aHTMLMediaElement
(think<audo>
&<video>
elements) to the specialMediaSource Object
Note: a new tab/window is not an
HTMLMediaElement
Note: even though they are created through
window.URL.createObjectURL();
Here's what's happening for the fiddle in your question's image and similar code that downloaded a video as
Blob
(where you downloaded the whole video-file's data/binary on the server using an xhr) or any other 'local' data:You are essentially using the 'bare' 'un-enhanced' File-API.
The
URL Store
is only maintained during a session (so it will survive a page-refresh, since it is still the same session) and lost when the document is unloaded.So, if your fiddle is still open, then fiddle-document (the document that created the
Blob URL
) is obviously not yet unloaded, and therefore it'sBlob URL
s are available to the browser (any tab/window) as long as it is not revoked!This is a relevant feature: you can build/download/modify a
Blob
in the browser, create aBlob URL
and set it ashref
to a file-download link (which the user can right-click and open in a new tab/window!!)Close the fiddle or revoke the
Blob URL
from theURL Store
and theBlob URL
is no longer accessible (also not in a different tab/window).Try yourself with your modified fiddle: https://jsfiddle.net/7cyoozwv/
In this fiddle it should now no longer be possible to load your sample image into a different tab/window after you copied the image url (once the image is displayed in your page).
Here I revoked the URL manually (
revokeObjectURL()
) as it is currently the best cross-browser method (partially due to the api not yet fully being stabilized).Also note: an element's
onload
event can be an elegant place to revoke yourBlob URL
.Here is what's happening to an
<audio>
or<video>
source linked to anMediaSource Object
using anMediaSource object URL
returned bywindow.URL.createObjectURL(MediaSource)
:The Media Source Extensions (MSE) also extend the
File-API
'swindow.URL.createObjectURL()
to accept aMediaSource Object
. The (current draft of the) URL Object Extension specifies that:Note that the current spec of the
File API
'swindow.URL.createObjectURL()
no longer has anautoRevoke
(orflag_oneTimeOnly
) boolean flag accessible to the programmer who should be usingwindow.URL.createFor()
for this purpose instead. I wonder when the Media-Source spec will mimic that (and for backward compatibility alias theircreateObjectURL()
to a newcreateFor()
extension (seems more appropriate as that is how it seems to be intended to work currently)).These resulting automatically revoked URL-strings are only intended to link the
src
of aHTMLMediaElement
(think<audo>
&<video>
elements) to the specialMediaSource Object
.I don't think that an empty
Document
(from a new tab/window) is a<audo>
or<video>
element.Perhaps "A quick tutorial on MSE"(source: MSDN) might help clarify the difference and basic use:
You (or a big-time player like youtube who will dynamically select supported technologies for playback on the client's platform (so there is no way to tell for sure what kind of youtube video URL's you are talking about)) could be using the new special
MediaSource Object
to play video's (or audio).This adds buffer-based source options to HTML5 video for streaming support (compared to to downloading a complete video file before playing or use an add-on like Silverlight or Adobe Flash to stream media).
Hope this is what you were after!