the making of a webdev - 2

The next thing after the doctype that I learnt is what forms the basis of today’s data exchange between the client and the server in HTTP - the “cookies”.

HTTP is a stateless protocol. To understand what this really means — lets look at what HTTP itself is built on top of, the TCP/IP. For every page that the browser requests, the TCP underneath the HTTP makes a “connect” with the server (a connect is a 3-way handshake in TCP/IP protocol), pass over the HTTP data and then “disconnects”. There is no persistent connection maintained between the client and the server between requests. So, the server has no way of connecting a previous request with the current one and draw a co-relation — this means, for example, if a user gives a login request, the client connects to the server, passes the login data to the server, the server does the login for the user (user is in login state) and then disconnects it. The next time around when the user does an action, the same sequence if connect-data-disconnect happens, but then how do the server figure out that this user had already logged in? (Remind you that once the disconnect happens, the state information is lost and every request that comes in to the server is a new request with no past history). There must be some mechanism which enables this conversation between the server and the client about the state of the application.

There are several mechanisms to associate subsequent requests and maintain some kind of a state and one such working, reasonably good enough mechanism is “cookies”.

There are several rules that a browser sticks to make sure cookies are not messed up:

1. browser has a local storage area where cookies are stored (on the harddisk of the user)

2. browsers support around 20 cookies per domain and 300 cookies in total and each cookie’s maximum size fixed at around 4k (this varies)

3. browsers make sure that they don’t give away this domain’s cookies to some other domain - the same domain policy. (essentially, this means, for example, that google’s cookies are not given away to yahoo’s server and viceversa)

The third point is very important and it remained not so visible to me, until sometime, when I tried to read/write someone else’s cookies. For example, try to read the expiry time of a google’s cookie and set it to something else using a javascript on your domain. I, actually realized why this script can’t do it by thinking a bit more - I could then give the url of the script and when they try to access the url, reset google’s cookies in anybody else’s computer to whatever time I want and just play.

Now there are variations to point #3 that make the cookies vulnerable like XSS (cross site scripting), which I’ll discuss in some other post. XSS falls under cookie stealing/theft (cookies can also be stolen in the network, which can be prevented using https), apart from this, there is the cookie poisoning (changing some values in the cookie without the knowledge of the server/client to produce some imitated change, which can be prevented by having a signature) etc.. But briefly, there are security and privacy concerns around cookies, that is what I understood.

The sequence of cookie exchange goes like this: Browser sends a request, the server sets the cookie in the HTTP header and sends it to the browser. Whenever the browser makes a request from the page which has cookie set, the cookie information is sent along with the request, so server figures out the state and acts accordingly.

Cookies can be set in server side (say, using a PHP script) like this:

<?php
//to set a cookie
setcookie('cookieName', 'cookieValue', $expiry, "/");
//to read a cookie
$cookie = $_COOKIE['cookieName'];
?>

Hmm.. when I wrote the setcookie(), I figured out that it has to be sequenced in the code in such a way that it appears before spitting out any HTML code (including any echos’ that you might’ve used. Otherwise, setcookie() simply returns false (the heaaders have already been sent, so cookie info cannot be set). Once the page is available, the cookies in the browser can be manipulated. Only that the next request to the server will go with the manipulated cookies.

Here an expiry time can be set as to when the cookie should expire. If the expiry time (in seconds) is provided, then a “persistent cookie” comes up (persistent cookies don’t expire, if I close the browser/session). The fourth parameter can tell which path this cookie is active on. There is also one more thing that the browser can do — send a particular cookie only for secure session (available as another parameter to setcookie).

On the client side, the browser can typically read and write the cookies through Javascript. I know not any other way to manipulate cookies on the clientside.

<script type="text/javascript">
document.cookie = "name=value; expires=time; path='/'; secure";
var cookies = document.cookie;
</script>

The first line to set a cookie and the second to read the values of the cookie.

Alright, the other ways to exchange data between the client and the server (of the state information) can possibly be:
1. Through URLs (have encoded strings that mimick cookie name/value pairs)
2. Hidden form variables and
3. possibly a few others methods..

Hmm.. they must be having their own difficulties or cookie seemed to be much reliable than these methods that having a cookie while browsing is almost like indispensable. I ponder on the reason why there is an option to enable/disable cookies - ya, obviously if a security vulnerability is found and the browser be used — atleast we could disable the cookies and have read data from the Internet, if not write!

Written by thanix on November 30th, 2007 with no comments.
Read more articles on basic and webdev.

the making of a webdev - 1

I wrote the first html page like this:

<html>
<title> Hello </title>
<body> <h1> Hello World </h1> </body>
</html>


I showed the code to my fellow senior webdev and was immediately brought to the attention of using proper “doctype” declaration, which looks like this:

<!DOCTYPE HTML PUBLIC “-//W3C/DTD HTML 4.01 //EN” “http://www.w3.org/TR/html4/strict.dtd”>

So the story goes like this: Use of appropriate “doctype” makes the browser behave differently as the scenario demands. In “strict” doctype, browser renders the page as per W3C’s specifications and the browser is said to operate in what is called as the “standards” mode. In certain other cases like when you don’t specify the doctype correctly, the browser falls back to imitate older browsers (which do not adhere to W3C spec) - this behaviour of a browser is “quirks” mode operation.

My question then came: “How do I detect what mode a browser is currently rendering a particular page in?” There must be a Firefox extension or some other code/script which can tell me this mode. I didn’t get an answer and I still do not know what is the right way to do this. (After note: read my update in the bottom of this post)

Then there are two other types of doctypes, other than “strict”. They are the “transitional” and the “frameset”. The use of “transitional” comes into play when you want to use presentational attributes in markup and certain presentational markup tags like <font> <strike> <u> etc.. In all ways, using “transitional” doctypes should be avoided, as the presentation can be very well done with the use of CSS. In the semantic markup world, (we will see what this is, sometime later) CSS is for presentation and markup is just for meaningful grouping of content. So, a good webdev should try to use “strict” doctype.

If you want to refer to the exact syntax of the doctype magic line that you would use, refer w3c’s site[1]

[1] http://www.w3.org/QA/2002/04/valid-dtd-list.html

I’m not sure what “frameset” doctype means. I just know that “<frameset></frameset>” will be used in the place of “<body></body>” tags. I’ve never attempted to use these frameset tags, so I don’t know what the browser does with it.

So, the first headache that I cleared in my webdev world is to make sure that I communicate to the browser how to read my code. I did byheart this magic line and put it in the very beginning of every html page that I write:

<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.01 //EN" "http://www.w3.org/TR/html4/strict.dtd">


UPDATE:

How do I figure out what mode a particular page is rendered on?
———————————————————————

Alright, a few of my friends updated me on how to figure out the Quirks mode. Its quite easy — in Firefox, Tools > Page Info (Ctrl + I) displays the “Render mode” of the browser, like this:

This site[2] has a nice bookmarklet which alerts you to say if the page is rendering in “Standards” mode or “Quirks” mode. By the way, if you do not know what a bookmarklet is — read on, others can skip this paragraph. When you go to the site[2], you will find a link that calls itself the bookmarklet (on the bottom of the page) which you should right click and add to the bookmarks toolbar. Then when you are in a page whose mode of rendering you want to figure out — just click on that bookmarklet, you’ll geta javascript alert (popup) saying the mode of rendering of that page.

[2] http://dorward.me.uk/www/bookmarklets/qors/

Written by thanix on November 29th, 2007 with 1 comment.
Read more articles on basic and webdev.

the making of a webdev - 0

I was thinking for a longtime to compile all the stepping stones that I encounter in my webdev (web developer) world in a collection called “the making of a webdev“, so this attempt. In all weirdness, this would come out as a naive man attempting to learn to code the web. I call it weird, because I, being a webdev, present this series/compilation so naked that you could find ample chances to call out “hey, you are a webdev?, really?” This comes with great amount of instinct, mistakes, practical usecases, inherited code, hearsays and a lot other, possibly “garbages” that got dumped when I listened with my “webdev” ears.

An artist becomes a “pro” by painting for money, the same applies for every other career. A “pro” has an exceptionally different knack, style and devotion attached to what he does, that really makes him a “pro”, much diffferent from someone who does it for hobby, the amateur hobbyist. Well, there are exceptions, but I’m talking of the larger class.

Probably, there is a lot more of you who haven’t coded a website, but think you make a decent “webdev” on the surface of your minds. Probably, you wrote simple, table-based HTML page, with or without using the so called tools like FrontPage, dreamweaver, and others. I was pretty much thinking like you and when I attempted to bring some content for a near “awesome” site, I drained out, I soon, found that I’m nowhere near the webdev zone. This is simply because web is no more 1.0, infant. It’s a grown up 6th class(grade) child now, I had to handle it in its own way, much different from how I’d handled it earlier.

I’m sure, this wouldn’t be like a powerpoint silver bullet or a tutorial or a training handout. This is more likely of the kind of sharing the know hows, whys and whats. Life is a relative phenomenon, so is what appears “simple” and “complex”. Somethings here might appeal to be drop dead “simple” and certain others very “complex”. I’m sure you will appreciate and take it in the right tone, as these are relative depending on one’s skill, experience and knowledge. I want to make sure that you take me to be standing on the same plane as yours — meaning this article here appears because I initiate it here, other than the fact that I initiated, there is nothing really that differentiates you from me. You could have better ways of putting out things, better skilled and better experienced in the same thing that I spit here. In that case, please open up the discussion through comments. I do not even claim to be the author of this series.
Lets being the roll from the next post, keep watching!

Written by thanix on November 27th, 2007 with no comments.
Read more articles on basic.

Aum…

This is my first post, so greeting you all with this basic sound of the universe “Aum”,

To demonstrate how I write markup using PHP, here is the code snippet below:


<?php
#aum code
echo <<< MARKUP
<h1 style="font-weight:bold;"> Aum </h1>
MARKUP;
?>

And you know what this code does, PHP simply understands that whatever is inside the MARKUP heredoc is spit as it is. The “<<<” marking is called the “heredoc”. The code marked with the heredoc is typically referred as the “heredoc code fragment”.

Written by thanix on November 26th, 2007 with no comments.
Read more articles on webdev.