I do not know how to frame the question. And I do not know how the below tag is working...
<img src="img.png?value=23"/>
This tag is working fine. And its rendering the image correctly.
Does the value=23 has some effect??? or It is been ignored by Browser??
I do not even know how to Google this!!! Is it like passing parameter to the Image??? If that is the case, how to retrieve the value attribute. Does the parameter has any sense
It depends on server, if you have png MIME type as text and you parse the files as if they were text files with php code then it has effect.
It really depends on configuration of server not a browser.
Morover, mod_rewrite can be used to change files that look like png to php files.
Adding parsing png files via php parser
AddType application/x-httpd-php .png
mod_rewrite
RewriteEngine On
RewriteRule ^([a-zA-Z0-9_\-]*)\.png$ img.php?value=$1
With these lineasdfasdf.png will be treated as img.php?value=asdfasdf
So in this case when you use $_GET['value'] on asdfasdf.png or img.php?value=asdfasdf. It will have effect.
If server is not configured to do such things and images are images(Yes i know it's briliant sentence) then it has no effect on common image.
To sum up.
It depends on server configuration not on the browser
If this image is dynamic in some way, then the server that's hosting this image must be generating the image from PHP code.
Take a look at the GD library, which lets you use PHP to generate images based on nothing or other images. The parameter must be passed to include that value inside the image (for example, an image that includes the text "123" or calculates using it somehow, for example a user ID).
Then an .htaccess on the server rewrites the extension of .png to .php (or maybe another one) to make it look like a genuine image to some libraries and crawlers, or scripts etc.
Another option, is that this is a simple image and that value is being ignored, or is just random to make sure the image isn't cached.
The value=23 only has an effect if the server uses it. The browser requests http://example.com/img.png?valud=23, so the server will see the parameter.
For example, with PHP, if your use $_GET['value'], and that variable changes what image is sent, then the value=23 is needed.
Parameters are often sent with images to specify a height or width, or to determine which image is loaded.
For this sample i don't know what does it mean
But it's possible to write
<img src="path_img.png?<?php time() ?>" />
to force your browser to download resource without using cache
It sure does!
For example, take a look at this piece of software that is intended to dynamically resize an image.
http://imageresizing.net/docs/basics
If done correctly, adding parameters to an image url could be very useful.
Edit:
As others point out, you need to ensure that the server knows how to handle the extra parameter. In this case it is intended to resize/watermark/rotate an image. It can certainly do other wonderful things.
value=23 is not ignored by your browser but by the server.
It's like passing parameters to the web server. For images it will be mostly ignored.
The arguments in a url are mostly used for getting some information about a specific item but can be used in more other ways. When talking about the images, the browser won't ignore the argument value=23 but the server you are using will.
But if the image is some sort of dynamic then it may be used in order to change the image's URL or other things.
Related
I have a question about referencing image in HTML. I have a single snippet of HTML code as
below, where I need to reference an image in a folder called static. The image has an extension of SVG
but it's name is dynamically created. If there a way for HTML to refer to this image by only referring to the file extension? The code below using a wild card doesn't work.
<p>
<img src="/static/*.svg" width="1000">
</p>
Additionally, can we add a logic in HTML such that if there is no SVG file in static folder, we don't render it; if there is one, then render it.
Thank you.
I don't think it's possible to do what you're asking with just HTML. However you can easily do this by adding an id to the tag and applying the attribute based on your condition. There are plenty of examples on the web on how to do this including one already answered here: Javascript set img src
This is possible with a server that is designed for this purpose. There is not a feature of just html that will do this, however. If you don't control the server on the backend, you probably can't get this to work, as it most likely will require custom backend code.
On the backend, you make a simple static html server that will match file patterns, and determine and serve the best match. You can do this any number of ways, and if you look up "how to make a static http server" for your favorite backend language, you likely will find an example to get you started, like these:
https://www.digitalocean.com/community/tutorials/how-to-create-a-web-server-in-node-js-with-the-http-module
https://blog.appsignal.com/2016/11/23/ruby-magic-building-a-30-line-http-server-in-ruby.html
https://stackabuse.com/serving-files-with-pythons-simplehttpserver-module/
You would then have to modify whatever base example you chose with your custom pattern matching code. Your server could be designed to do whatever you wanted with the request you send it, including the scenario you described.
This works because an img tag like the one in your example causes the browser to make a GET http request to your server, passing on the url in the src attribute. So, if you control that server, you can have it respond in any way you want, including treating specific characters like * specially.
I am setting up a website that I want no one to know the URL for. For example, I send them a link that actually goes to the page, but the URL in the bar at the top has a completely different URL that I don't own. I'm not sure if this can be done in PHP, HTML, or the .htaccess file.
This is not possible, unless
you control the systems of the visitors (then you could, for example, change their DNS servers), or
you find and exploit a bug in the browser/system.
You can make a link anchor text look like it leads to a specific domain not under your control, but the real URL will be used in any case. Example: http://wikipedia.org/.
Learning how to utilize Bootstrap, I noticed that the thumbnails had strange markup for the image source (at least, strange to me.)
<img data-src="holder.js/260x120" alt="260x120" style="width: 260px; height: 120px;" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQQAAAB4CAYAAAAUn4wEAAAGP0lEQVR4Xu3aPUsdWxQG4LEwKiSFTbQTsUwsRfDvp7KRVBFrEVIEsRFT+HHvHJjDODrH96ghQ9aT5nLD8rjXs/Z+3TNx5fLy8qHxhwABAv8LrAgE+4AAgU5AINgLBAjMBQSCzUCAgECwBwgQeCrghmBXECDghmAPECDghmAPECCwQMAjg+1BgIBHBnuAAAGPDPYAAQIeGewBAgQSAe8QEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAKDJobRJIBARCoqSGQBEBgVBk0NokkAgIhERJDYEiAgKhyKC1SSAREAiJkhoCRQQEQpFBa5NAIiAQEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAKDJobRJIBARCoqSGQBEBgVBk0NokkAgIhERJDYEiAgKhyKC1SSAREAiJkhoCRQQEQpFBa5NAIiAQEiU1BIoICIQig9YmgURAICRKaggUERAIRQatTQKJgEBIlNQQKCIgEIoMWpsEEgGBkCipIVBEQCAUGbQ2CSQCAiFRUkOgiIBAmOCgT09Pm4uLi/nKPn361BweHj5a6eXlZfP9+/fm/v5+9vfP1ZyfnzdnZ2fzr9vd3W329vZe3fHJyUnTft+tra1mf3//0ecka37v9by6EV84KiAQJrY5ukM3XFb/wA/DoKvtH9Th4etqXhsK/c8bBkKy5vdez8TG9s8sRyBMaJS3t7fNt2/fmru7u6Y7uP2D9PXr1+bz58/N8fFxc319/aRmZWWlOTo6atbW1uY13eHtfoKvr6/Pbhurq6tx58MD3w+EZdf8HuuJF65waQGBsDTZn/uC7vB3B3tjY6MZHridnZ1ZaLSPCu3hb2uGf/o3iDZEtre3Z1f99hHj4eFh9nU3NzfzR44ufIZf1w+f9nu0YfL79+9HjwzJmjc3N+ffa2w9z/Xx56R98piAQJj43hge0g8fPswOV/vf9oBeXV3NOuj/1B4e/mGwdIey+8nffs7BwUHT/n978+g+qw2d9jby8ePH5suXL09uHWN0Y2vuwmhsPRMfRYnlCYQJj7k7kO0h7d4hjD2Lt20MaxbdNNqXi/3bR3uL+PnzZ9P/mj5Nfy3PvVTsahet+aX1THgUZZYmECY66v7B6h+kfiAM3zN0db9+/Zr960JyANM3/0kgvLTmZD0THUeZZQmECY567GC1S00eB7rHiuSK3r8ljN0O2u/7UiC8dc3tDcWfvy8gEP7+DB6tYNHBWjYQ2s966SXe8PcHxh4HFgVCuuZkPRMbR7nlCISJjbx70bfMs/zwTX/6z47920b70vDHjx+zm0AXIuk7hNes+S3/DDqxkf1TyxEIExrn2C8cdUt87ncT+stf5heTnvuJv+iQjt0Q3rrm1/6i1ITG9k8tRSBMaJzD6/twaf3DMzyIz131F70w7L7X2Iu+4eeNBcIya05fYE5oJOWWIhDKjVzDBMYFBILdQYDAXEAg2AwECAgEe4AAgacCbgh2BQECbgj2AAECbgj2AAECCwQ8MtgeBAh4ZLAHCBDwyGAPECDgkcEeIEAgEfAOIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAomAQEiU1BAoIiAQigxamwQSAYGQKKkhUERAIBQZtDYJJAICIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAomAQEiU1BAoIiAQigxamwQSAYGQKKkhUERAIBQZtDYJJAICIVFSQ6CIgEAoMmhtEkgEBEKipIZAEQGBUGTQ2iSQCAiEREkNgSICAqHIoLVJIBEQCImSGgJFBARCkUFrk0AiIBASJTUEiggIhCKD1iaBREAgJEpqCBQREAhFBq1NAonAfyCREfyopr43AAAAAElFTkSuQmCC">
What's going on here, and why is this being done? Is the image somehow saved to local storage at some point in base64?
To clarify, I'm asking about the src="image:/ part.
What you are seeing is not the HTML5 data- attribute, but the data URI scheme. To quote Wikipedia:
The data URI scheme ... provides a way to include data in-line in web
pages as if they were external resources. This technique allows
normally separate elements such as images and style sheets to be
fetched in a single HTTP request rather than multiple HTTP requests,
which can be more efficient.
What you're seeing is the base64-encoded image data, in this case a PNG. When browsers see this, they decode the data as instructed, and display it as if it were an external resource.
Given this image's size, the creators of Bootstrap rightly believe it is more efficient to inline the image like this rather than keeping it separate. Had they kept it separate, it would require an additional HTTP request to load the image, which increases the total load time of the page.
In the case of Bootstrap, what I think you are seeing is Javascript being used to generate the data that goes in the src attribute.
If you look at the raw source (not the source in the inspector), you will probably not see the src attribute, only data-src.
The data-src attribute is an instruction to javascript to use the holder.js script to generate the data to go in the src.
So holder.js generates the image, which is then loaded into the img as a data uri as explained by the other answers.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it safe to serve an image on the web without an extension?
I'd like to use something like <img src="advertisements/12" style="border: 1px solid"> in a page. FireFox won't display it, which makes me think I have to have a file extension for the file. Am I right here (for the other browsers too), or does FF like mime types?
EDIT
I've tried all sorts of stuff and it still won't work. I now put an extension on the file correctly (.swf for Flash, for example). I've changed the directory, etc etc. When I call file_exists(), The file is there, all happy and such, however I absolutely cannot get it to render on the page. It could either be a .PNG in an img tag, or a Flash object. Neither works. What am I doing wrong :-(
Also, if I rename a non-uploaded file to the file the script is looking for, that works fine, but the uploaded ones don't...
Yes, you should be able to.
Browsers initially don't look at the filename, they look at the MIME type listed in the Content-type header in the response from the HTTP server. If the content type is image/jpeg, or png or gif or whatever, things are good and it will happily render the image.
If there is no valid MIME type, some browsers will try to guess what the type is. They'll look at the extension of object being request, or they'll look at the first few bytes. If that fails, then you get a redex.
That used to cause some woes back in the early days of Firefox / Firebird, because it was strict about mime types and often refused to render something without a valid MIME type. IE made a guess, and so many sloppy web servers would serve up pages that would render fine in IE, but not in others. These days though, things are much better.
So, as long as your web server is providing the right MIME type when the img object is requested, you'll be good to go. If you are having problems, check what your web server is doing when "advertisements/12" is requested.
What is the server returning? The file extension isn't used for anything, really. The browser is checking for the Content-type header, which should be something like image/jpeg or whatever type of image you're serving.
This is used pretty often in sites which dynamically serve images, often from a database. I've seen plenty of image URLs like image.aspx?id=37 which, while it technically has an "extension" doesn't really mean that it's an image. It's all in the HTTP header values.
Providing a MIME type might help, although the server should theoretically be providing the correct one. If it's a specialized PHP (or similar) script that's serving up the image, you have to make sure you set the HTTP Content-Type header to the appropriate MIME type.
If you want to avoid using the <img> tag, you can use <div> in conjuntion with CSS backgrounds, but that's not going to help if the browser doesn't recognize advertisements/12 as any known image type.
2022 Edit:
Wow! Well, it worked good enough back then... But, for modern day detection there is https://www.php.net/manual/en/function.exif-imagetype.php ...with webp detection as of v7.1.
I found myself with similar image viewing problems after renaming images uploaded from web forms. Since I could have a mix of gif, jpg, jpeg, or png files I went looking at the file properties.
What I ended up doing was checking the MIME type (which is usually within the $_FILES array while processing the uploaded files) and appending an associated extension to the file name.
if($_FILES[$fieldname]['type'][$key]=='image/gif') {
$ext='.gif';
}
if($_FILES[$fieldname]['type'][$key]=='image/jpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/pjpeg') {
$ext='.jpg';
}
if($_FILES[$fieldname]['type'][$key]=='image/png') {
$ext='.png';
}
List of common image mime types.
--Which did fix my problem as my browser was trying to download my images as binary files without the filename extension.
Server - Debian, Apache 2.2, PHP 5.3
Web Client - Kubuntu 11.10 ,Firefox
normally you go on a website and by right click you can choose to see the source code. Or you just use firebug and select an element you want to analyse. Is it possible to write the source code in the URL so that it wouldn't be shown by right click + choosing or selecting an element?
I'm asking because I've already seen this phenomenon once by using an iphone simulator in safari.
Any ideas or hints what I'm exactly looking for? Your help would be great.
Edit: Based on wrong information. You can see the sourcecode by rightclicking. But the url still contains all information about the site. I'll get back to you as soon as I got more information to write them down clearly. Sorry for all the confusion.
Edit: This is the code in the url containing information about the site.
data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8aHRtbCBtYW5pZmVzdD0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvc3BvcnRpbmdiZXRQb3J0YWwubWFuaWZlc3QnPg0KPGhlYWQ%2BPHRpdGxlPlNwb3J0aW5nYmV0PC90aXRsZT4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSdjb250ZW50LXR5cGUnIGNvbnRlbnQ9J3RleHQvaHRtbDsgY2hhcnNldD11dGYtOCc%2BDQoJPG1ldGEgbmFtZT0ndmlld3BvcnQnIGNvbnRlbnQ9J21heGltdW0tc2NhbGU9MSwgd2lkdGg9ZGV2aWNlLXdpZHRoLCBoZWlnaHQ9ZGV2aWNlLWhlaWdodCwgdXNlci1zY2FsYWJsZT1ubywgbWluaW11bS1zY2FsZT0xLjAnPg0KICAgIDxtZXRhIG5hbWU9J2FwcGxlLW1vYmlsZS13ZWItYXBwLWNhcGFibGUnIGNvbnRlbnQ9J1lFUyc%2BDQogICAgPG1ldGEgbmFtZT0nYXBwbGUtbW9iaWxlLXdlYi1hcHAtc3RhdHVzLWJhci1zdHlsZScgY29udGVudD0nYmxhY2snPg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBsYW5ndWFnZT0namF2YXNjcmlwdCc%2BDQogIGlmIChkb2N1bWVudC5yZWZlcnJlciA9PSAnJykNCiAgew0KICAgd2luZG93LmxvY2F0aW9uPSdkYXRhOnRleHQvaHRtbDtjaGFyc2V0PXV0Zi04O2Jhc2U2NCxQR2gwYld3JTJCUEdobFlXUSUyQlBHMWxkR0VnYm1GdFpUMG5kbWxsZDNCdmNuUW5JR052Ym5SbGJuUTlKMjFoZUdsdGRXMHRjMk5oYkdVOU1Td2dkMmxrZEdnOVpHVjJhV05sTFhkcFpIUm9MQ0IxYzJWeUxYTmpZV3hoWW14bFBXNXZMQ0J0YVc1cGJYVnRMWE5qWVd4bFBURXVNQ2MlMkJQRzFsZEdFZ2JtRnRaVDBuWVhCd2JHVXRiVzlpYVd4bExYZGxZaTFoY0hBdFkyRndZV0pzWlNjZ1kyOXVkR1Z1ZEQwbldVVlRKejQ4YldWMFlTQnVZVzFsUFNkaGNIQnNaUzF0YjJKcGJHVXRkMlZpTFdGd2NDMXpkR0YwZFhNdFltRnlMWE4wZVd4bEp5QmpiMjUwWlc1MFBTZGliR0ZqYXljJTJCUEUxRlZFRWdhSFIwY0MxbGNYVnBkajBuY21WbWNtVnphQ2NnWTI5dWRHVnVkRDBuTVR0VlVrdzlhSFIwY0hNNkx5OTNaV0poY0hBdWJXWjFjMlV1WTI5dEwxTndiM0owYVc1blltVjBMMmx3YUc5dVpTOXBibVJsZUMxbGJsOUhRaTVvZEcxc1AybGtQVFUzTkRVME1qa3lNRUUwTURRMk1UVXdNVE01TUVaRFFUTTRNREJFTkRnNEpteHZZMkZzWlQxbGJsOUhRaVpoWm1acGJHbGhkR1ZKUkQwblBqd3ZhR1ZoWkQ0OGMzUjViR1UlMkJZbTlrZVh0aVlXTnJaM0p2ZFc1a0xXTnZiRzl5T2lNd01EQTdkR1Y0ZEMxaGJHbG5ianBqWlc1MFpYSTdZMjlzYjNJNkkwWkdSanRtYjI1MExXWmhiV2xzZVRwQmNtbGhiQ3dnU0dWc2RtVjBhV05oTENCellXNXpMWE5sY21sbU8yWnZiblF0YzJsNlpUb3lNSEI0TzMwOEwzTjBlV3hsUGp4aWIyUjVQanh3UG14dllXUnBibWN1TGk0OEwzQSUyQlBDOWliMlI1UGp3dmFIUnRiRDQ9Jw0KCSB9DQogICAgPC9zY3JpcHQ%2BDQogICAgPGxpbmsgcmVsPSdhcHBsZS10b3VjaC1pY29uLXByZWNvbXBvc2VkJyBocmVmPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9JbWFnZXMvV2ViQ2xpcEljb24tZW5fR0IucG5nJz4NCiAgICA8bGluayByZWw9J3N0eWxlc2hlZXQnIHR5cGU9J3RleHQvY3NzJyBocmVmPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9jc3MvbWFpbi1lbl9HQi5jc3MnPg0KICAgIDxsaW5rIHJlbD0nc3R5bGVzaGVldCcgdHlwZT0ndGV4dC9jc3MnIGhyZWY9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL2Nzcy9UcmFuc2l0aW9ucy5jc3MnPg0KCTxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL3V0aWxpdGllcy5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL3NldHVwLWVuX0dCLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvbWFpbi5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL1RleHQuanMnIGNoYXJzZXQ9J3V0Zi04Jz48L3NjcmlwdD4NCiAgICA8c2NyaXB0IHR5cGU9J3RleHQvamF2YXNjcmlwdCcgc3JjPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9QYXJ0cy9QdXNoQnV0dG9uLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvUGFydHMvQnV0dG9uSGFuZGxlci5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL1RyYW5zaXRpb25zLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvUGFydHMvU3RhY2tMYXlvdXQuanMnIGNoYXJzZXQ9J3V0Zi04Jz48L3NjcmlwdD4NCjwvaGVhZD4NCjxib2R5IG9uTG9hZD0nbG9hZCgpOyc%2BDQogICAgPGRpdiBpZD0nc3RhY2tMYXlvdXQnPjxkaXYgaWQ9J3NlbGVjdGlvbi1wYWdlJz4NCiAgICAgICAgICAgIDxkaXYgaWQ9J2xhbmRpbmdwYWdlJz4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdjZW50cmVUb3BCRyc%2BPC9kaXY%2BPGRpdiBpZD0nY2VudHJlQm90dG9tQkcnPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2xvZ28nPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2ljb24nPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2Rpc3BhbHlib3gnPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDInPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9J3ZpZXcyJyBpZD0naXBob25lJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSd2aWV3MicgaWQ9J2Nhc2lubyc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgPGRpdiBpZD0nZGlzcGFseWJveDMnPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDUnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDYnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDcnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDgnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDknPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEwJz48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBpZD0ndGV4dHAxMSc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwMTInPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEzJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj48ZGl2IGlkPSdpbnN0YWxsLWFwcC1wYWdlJz4NCiAgICAgICAgICAgIDxkaXYgaWQ9J2luc3RhbGwnPg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2NlbnRyZVRvcEJHMSc%2BPC9kaXY%2BPGRpdiBpZD0nY2VudHJlQm90dG9tQkcxJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdkaXNwYWx5Ym94MSc%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwMyc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwNCc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgPC9kaXY%2BDQogICAgICAgICAgICAgICAgPGRpdiBpZD0naWNvbjEnPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2xvZ28xJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdidXR0b24yJz48L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4=
No, it's not possible to hide a website's source code. The reason for that is simply that the browser needs that code to display the website, so whenever you see a website, you'll always be able to see as much code as is needed to make the website look like that.
You can mangle the code a bit, but as you have said yourself, things like Firebug are able to display the current state of a website, so you'll also be able to see the correct code.
edit
Just a note: Just because Safari with an iPhone user agent isn't able to display the source code, it doesn't mean that the code is not there or somehow encrypted into the URL. If you can see the website, the code is there.
I guess it's a bug (or a feature?) that Safari isn't able to display it in iPhone mode (maybe because the iPhone itself isn't able to display the code either).
edit 2
Okay, it indeed set the URL to the following for me:
data:text/html;charset=utf-8;base64,PGh0bWw%2BPGhlYWQ%2BPG1ldGEgbmFtZT0ndmlld3BvcnQnIGNvbnRlbnQ9J21heGltdW0tc2NhbGU9MSwgd2lkdGg9ZGV2aWNlLXdpZHRoLCB1c2VyLXNjYWxhYmxlPW5vLCBtaW5pbXVtLXNjYWxlPTEuMCc%2BPG1ldGEgbmFtZT0nYXBwbGUtbW9iaWxlLXdlYi1hcHAtY2FwYWJsZScgY29udGVudD0nWUVTJz48bWV0YSBuYW1lPSdhcHBsZS1tb2JpbGUtd2ViLWFwcC1zdGF0dXMtYmFyLXN0eWxlJyBjb250ZW50PSdibGFjayc%2BPE1FVEEgaHR0cC1lcXVpdj0ncmVmcmVzaCcgY29udGVudD0nMTtVUkw9aHR0cHM6Ly93ZWJhcHAubWZ1c2UuY29tL1Nwb3J0aW5nYmV0L2lwaG9uZS9pbmRleC1lbl9HQi5odG1sP2lkPTU4NjIwNEE2MEE0MDQ2MTUwMTM5MEZDQTFBQTdGNDFBJmxvY2FsZT1lbl9HQiZhZmZpbGlhdGVJRD0nPjwvaGVhZD48c3R5bGU%2BYm9keXtiYWNrZ3JvdW5kLWNvbG9yOiMwMDA7dGV4dC1hbGlnbjpjZW50ZXI7Y29sb3I6I0ZGRjtmb250LWZhbWlseTpBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToyMHB4O308L3N0eWxlPjxib2R5PjxwPmxvYWRpbmcuLi48L3A%2BPC9ib2R5PjwvaHRtbD4=
This however just encodes to a loading & redirect page that itself redirects to a different webpage with a special session-like parameter. I guess they didn't want to create real server side sessions for this and just put the parameter into the redirect page and encoded the whole junk using the data: URI to not create a custom page for it. This however does neither help the browser (in terms of speed or anything else) nor does it hide the source code, as you can just decode it again to see the original source code.
What you're referring to is the data URI scheme, which allows base64 encoded data to be included locally (within a request), where normally http/etc URLs are used to initiate new requests.
The data URI scheme is a URI scheme
that provides a way to include data
in-line in web pages as if they were
external resources. It tends to be
simpler than other inclusion methods,
such as MIME with cid or mid URIs.
Read the Wikipedia page for more details: http://en.wikipedia.org/wiki/Data_URI_scheme
i don't know what you're trying to achive, but if you want to hide the source code because of "anybody can steal my code": that isn't possible. the sourcecode has to get to the browser in any way, so the browser can display it - and if the code is on the client-machine (in the browser) there will always be a possibility to grab it.
Even if you restrict right clicking, or viewing the source, it is impossible to hide it from everybody. Also, placing it in the URL would be bad, very bad (I can't even imagine it).
the html is needed for the browser to render the UI. You can't hide it.
You could compress and obfuscate the javascript though, to make it difficult to read and understand. But that's evil :)
Internet Explorer has a character limit of 2048 characters, so you would have to compress the content and pray it will fit in the url after it's been base64 encoded. Then you can use javascript to decode it. It will also be extremely difficult to update your pages or allow for bookmarking. It could also result in users exploiting the system.
Chances are nobody will want your sauce code anyway, and if they did, it wouldn't affect you one little bit. Facebook shows it's sauce, I don't see it's popularity dropping. So just stick with serving your pages the normal way.
1. The length of an URL is limited, so that you couldn't write a whole page into it even if it were possible.
2. Once a thing has been displayed at a client machine the code cannot be protected.
(well, using javascript right-click disabling could repell a few noobs, but it is still fairly easy to grab the code)