This is strayer's / ASP's BZFlag site, test-platform and private homepage with TVinfo and other stuff.


Xtra stuff


---Info---  

XML files  
(BZFlag, TVinfo)

Firefox  
(search-plugins)

Inline media  

ToDo list  

Website statistics  

What's new?  
(2004-12-02)




Select a look


Valid XHTML 1.0!
Valid CSS!

News
number of entries:
51

last entry:
2006-10-07

by:
STRAYER


Guestbook
number of entries:
49

last entry:
2011-09-24

by:
strayerfan


BZFlag
number of servers:
125

number of players:
15

last query for:
3 min


TVinfo|DE
number of stations:
204

telecasts:
165352

data since:
2017-11-06

data until:
2017-12-04


Statistics
visits*:
???

hits*:
???

*:o) without strayer (o:


Sitemap


Enjoy www.strayer.de!

The data above are cached for a short while to enhance the performance.

Inline media


...are media which are embedded/integrated in documents without just setting a ressource link. The best counter-example to inline media are normal HTML sites where these media are given as ressource links with different attributes. The following article will refer especially to images by explaining the method of embedding media directly into documents.

inline image
<img src="./pics/favicon.png" alt="inline image" width="150" height="160" />

As you can see in the example above, the attribute 'src' of the HTML tag 'img' contains a ressource link. The application that analyses the document and the link to the image, for an HTML site normally a web browser, can (down)load the image from the given location. For some reason, it's not wanted or not possible to load another file via the analysing application. One example might be an HTML-email where it's not allowed to attach further files like images. Referring to RFC 2397 and RFC 2557 ('Request for Comments') it's allowed to include the image data ('image stream') directly into documents.

inline image
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAJYAAACgBAMAAAAcDIhhAAA
AD1BMVEUAAAARKg0oQCXA1sDG/8bRXuTeAAAAAXRSTlMAQObYZgAAAAlwSFlzAAAOxAAA
DsQBlSsOGwAAAMFJREFUaIHt18ENwzAMQ9Gs4BWyQlbI/jMFdoEKEahUQC9l8XmUxedbj
GxjZvs2LwULy8pS4F5FMVhYrtZKVEaVcgULy8Z67nWzFCwsGyt9/1eOmbKnTuVbgoVlZZ
WV8hIsLC8r3o7jHVVWBzHL7xAWlouVds6Zcc+aqTuxsKytBEZFzbCw/smKcmOGheVvldv
PKhaWl5V+bhtgzWBhOVtRUUl7WFiuVhfsMFhYVlaASk3CBwYLy8pSakpbwML6VesCmOfu
PMgWmoQAAAAASUVORK5CYII="
alt="inline image" width="150" height="160" />

The example above demonstrates that the value of the attribute 'src' consists of different parts:

data:[<mediatype>][;base64],<data> (see RFC 2397)
data
... indicates that the following information are a direct image stream instead of a link.
<mediatype>
... stands for the kind of media.
base64
... is optional and shows that the following data stream is base64 encoded. If this statement is missing it will be an ASCII string.
<data>
... is the data stream itself.
By this example you can see clearly that such a simple picture can cause a very long character string as base-64 coded 'data queue'. And this is the weak point of this kind of embedding types of media, because according to RFC-1866 HTML documents aren't allowed to contain strings of infinite length. That's the reason why only 'small' pictures are suitable. These limits either don't exist or they are there in different dimensions (sizes) in other document types (like XML).

The technique of embedded media (it's a picture in this case) is used in my guestbook on this web page because undesired entries made by so - called spambots (which enter rubbish or advertisement) are to be prevented. A picture is to be created, containing a particular by chance – generated code that must be read off by the user and entered for control, so that the message will be really saved.
The advantages of an embedded picture in contrast to other alternatives arise out of the kind of the generating possibility of the picture and the according HTML-code:
  • prevention of caching of embedded pictures (useful with CAPTCHA – pictures)
  • abandonment of cookies
  • abandonment of storing valid code for a session (and of sessions in general)
  • abandonment of lists containing valid codes (often used, but it's rather problematic)
  • abandonment of passing-on of code to a separate script file, which creates the picture separately (in general PHP scripts can't create HTML-code and display pictures at once)
  • generation of the code and the picture in a single file and abandonment of databases and/or additional files for code storage
According to this the PHP script creates the code, the picture as well as a hidden input field, containing the code which is embedded by a one–way encryption method (like MDS, SHA1 or CRC 32). This code is used as a string to compare the code entered by the user after the form has been sent. If they are conform the whole entry is saved. One–way encryption methods combined with short codes are adequately save for such less awkward applications like guest books. :o)

But this method has a further disadvantage: Microsoft's Internet Explorer up to and including version 6.x (the devil's worrisome bother) isn't conform with the upper listed RFCs and doesn't support this method. I don't know how it works with the IE versions 7.0 and higher, but I must admit I don't really care about it. As far as an IE user looks at this article and notes that he can see the picture taken as example, so this is caused by a Workaround by Dean Edwards, which I used here. Those of you who want to learn more about this are to read the information on his webpage.

In this sense: lots of fun with messing around. I have spent lots of time on it, too, until I have had enough of it... ;o)

...(2005-08-29)...