Yes, it's been quite some time since web_training has had a training exercise posted to it, so I thought I would go ahead and write some up for it. =)

This first one involves a problem that we don't see that often on the board, but it does come up from time to time. Please read it over and think about it, and then post a comment with what you would say in a screened answer, along with links to any FAQs you might provide. If you don't feel up to writing a full-blown screened but still have an idea as to what could be the cause, please feel free to leave a comment with your thoughts. All comments will be screened. Without further ado...

---

Summary: URGENT! plz hlp me!!!! THX!!!

Hi, all! Anyway, here's what's going on. So I've added this cool gal to my Friends list, right? We finally got over our long-term grudge that started back in 2001 when we were in grade school, and now we're BFFs!!! W00T!!!

But here's the problem. I wrote a whole bunch of F-Locked posts that talked smack about her back then, and I forgot all about them until someone reminded me. So I need to either privatize them or delete them... but I can't! :((((( Every time I try, I always get this error:

Client error: Invalid text encoding: Cannot display this post. Please see http://www.livejournal.com/support/encodings.bml for more information.

I just don't have time to visit this encodings.bml page because time is of the essence here! She could be reading those bad posts about her any minute now!!!1!one!! Please, tell me what I can do to edit or delete these posts? Or can you even do it for me instead? Help me, pretty please????? <333333333

---

Will you, the valiant Support volunteer, be able to help this user-in-distress solve their plight? Tune in next week for the spine-tingling concusion to this quandary!

All characters represented in this training exercise are a work of fiction. Any resemblance to any real or fictional personality is purely coincidental. No bunnies or sharks were harmed for this training exercise.

For anyone that posts here: the newpost minsecurity has been set to "public", so if you want to make a protected post in this comm, you'll have to do it manually from now on. Thanks!

What are cookies, anyway? Are they tasty?

A cookie is a small bit of information about you that the web server sends to your client. Your client then offers that information to the web server every time you visit a page on it thereafter.

Cookies are frequently used by web sites as part of their login process; when you enter your username and password, the server creates a cookie that contains a unique identifier, which your browser then stores and sends to the site whenever you visit, notifying it that you really are who you say you are.

This all sounds great. So what's the problem?

Certain less scrupulous sites may use cookies to track what kinds of advertisements you have seen or what sites you have visited to build up a list of advertising preferences. Because of this, many users may have browser options or third-party programs that restrict or eliminate the cookies that sites may store on their machines. This, unfortunately, interferes with that user's ability to log into LiveJournal, since a user's browser must accept a cookie to allow them to log in.

Further, some network settings on the part of the user or their internet service provider may have the same effect. Particularly, some internet service providers use proxies to serve requests; a proxy is a machine that sits between you and the site you are trying to contact, intercepts your request, and contacts the site on your behalf. Proxies are frequently used to supplement browser caches to improve speed of access for individual web sites. Unfortunately, some of them interfere with appropriate transmission of cookies, as well, causing users to be unable to log in or update their LiveJournal site preferences.

And, lastly, some users may have their clocks set in a vastly wrong way. Cookies contain expiration dates; if the client thinks that the cookie that the server is trying to set ought to have expired last week, it will throw it away without comment.

So what can be done?

Users may clear the cookies from their browser, to ensure that an old version of a cookie is not accidentally being used instead of a new one. Users may check their browser settings to ensure that LiveJournal is named as a "trusted" site, indicating that it may set cookies on the machine. They also may check other security programs to ensure that none of them are deleting cookies from LiveJournal. They may need to check their local network for devices that might interfere with cookies; some routers have been known to do this. And, lastly, they may contact their internet service provider to ensure that cookies are being properly set.

There is a FAQ which addresses precisely these issues, and this FAQ should be referenced whenever a cookie problem is suspected.

How can I tell if something is a cookie problem?

Here are some common signs of cookie problems:

• The user logs in successfully, but then is logged out whenever they visit a new page on LiveJournal.
• The user changes their page layout or language, but the setting never seems to stick between pages.
• The user is unable to use some feature they should be able to use while logged in, or unable to see protected entries they believe they should have access to.
• The user receives a message that says "invalid cookies". This is specifically a sign that they've recently switched to a paid account, and a separate FAQ is devoted to this issue.

It is also important to note that any of the above problems may also occur due to caching; for that reason, the FAQs that are used in these cases contain links to the cache-clearing FAQ. It should not be necessary to link to it yourself in most cases, although if the user is particularly confused and has already seen the cookie-related FAQs, you may need to make such a reference.

What does "Bind cookie to IP address" mean, then?

In theory, you will be sitting at a particular computer which has a unique IP address on the Internet. When your browser sends a request to LiveJournal, your IP address is one of the pieces of data that the server picks up. If someone else snoops on your session and tries to use your login cookie from their own computer then it will be coming from a different IP address. So you can tell LiveJournal that your login cookie isn't valid if it comes from any other address than yours, and this will protect you from people trying to steal your cookies.

Note that this doesn't stop you from logging in from another computer with your username and password. LiveJournal will generate a different cookie for that login, and you can thus bind it to a different IP address.

So what can go wrong?

If you are on dialup, or a connection which often changes its IP address, then binding your cookie to your IP address will cause you to get logged out every time the address changes (which, for a dialup connection, usually means every time you connect to the Internet).

More importantly, some ISPs use clusters of web proxies. When you send a request to LiveJournal, they intercept it and send the request on your behalf. Sometimes each request will come from a different machine within the cluster. If you have bound your cookie to "your" IP address, you will actually have bound it to the address of one particular proxy machine in the cluster. If a different proxy picks up your next request then you'll appear to be logged out again. This can cause you to appear to be randomly logged in and out, depending on which proxy your request hits on the way to LiveJournal.

The solution to this is of course to try disabling the "Bind cookie to IP address". This is one of the steps listed in the FAQ, so you don't need to state it explicitly to the user unless they have regreened the request.

What is a memcache? Is it like a cache that tells you what X-man you are?

If you're not familiar with web caching in general, hit up the web-cache training post before reading this one. All set? Good.

Memcache is a system created by the LiveJournal development team to reduce load on their database servers. (It has since been adopted by other sites, but its primary users and maintainers are still affiliated with LiveJournal.) To explain what it's for, we're going to have to explain a little bit about how LJ (and lots of web apps) work. The way a page on LiveJournal is generally loaded is this:

Trust me, it's less complicated than it looks. The lines of this color represent an actual connection, the lines of this color represent paths the connection could have taken, and lines of this color represent the database's internal syncing mechanisms. So here's what's happening:

1. You enter a LiveJournal URL and hit return.
2. Your browser talks to the load balancer.
3. Unbeknownst to your browser, the load balancer goes out to find a web server to answer the request, and puts you in touch with that server.
4. For (mostly) unchanging content like images, this is as far as we need to go. The web server sends the content back to your browser. But most pages on LJ aren't unchanging; they're dynamic. So what happens next is that the web server goes to ask the database server to generate the content on it.
5. The database server digs out your journal entry (or any other dynamically-generated stuff) from its internal storage, and passes it to the web server, which then integrates it into the page and sends it back to you.
6. If you changed anything in the database when you hit the page (by updating your journal, for instance), the database server that you were talking to passes those changes to the other database servers. This process is called replication.

This picture gets more complicated when we talk about clusters and I'm elliding some subtleties about master/slave database relationships, but this is close enough for government work.

The problem with this system is that the connection to the database server is expensive, because that's where all the data really is and accessing it frequently involves talking to a bunch of disks. (When dealing with computers, disks are generally the slowest part of the system.) Ideally, as few connections to those servers as possible should happen. So what memcache does is store the results of your database query on one of the web servers when you make it, just like your browser cache does. Next time someone asks for that same piece of data, the web server figures out which server should be caching it, and checks there first before getting in touch with the database server. When you change that piece of data, the web server erases it from the cache when the database server is updated so that the next query will see the real data instead of whatever was there last time someone looked at the page. This cache is stored entirely in the memory of the machine (hence the name memcache), which makes it very fast.

This all sounds great, or at least it did once my head stopped hurting. So what's the problem?

There are a lot of things that can go wrong here, but there are two that are of primary concern to us:

Replag

Replag is short for "replication lag". This occurs when the database server that you sent your data to doesn't immediately update the other database servers about it, usually because it's a lot busier than it usually is for some reason. If this happens, you might connect to the wrong database server and see the old version of the data instead of the new one, and if it's a piece of data that gets memcached, that old data might get put into the cache. If it's not memcached, this can result in someone seeing different versions of the page every time they reload it (since which web and database server you get sent to is, from your point of view, totally random.

Stale Memcache

If the memcached version of a page isn't cleared when the page is updated, the old version will still appear to be there (even if the new version has been properly stored in the database). This looks very much like a browser caching problem, except clearing the cache doesn't help with it.

So what can be done?

Most problems like this can be solved by time. And because they initially resemble caching problems, this means we'll never see them; we tell the user to clear their browser cache, and in the time between when we say this and when the user reads the answer, the blockage has been cleared and all is right with the world again. If the page gets updated by the user, that will also generally clear things out. Some problems of this kind are more persistant, though.

Web SHes have access to a tool that lets them clear the memcache for a particular user. In cases where a page is stuck in an old state, we're 100% sure that the page should be updated, and the old state is visible to the volunteers as well as the user (hence not browser cache), this tool can be used on the user that owns that page to force it to update. This is not a step that should be taken lightly, because it puts a lot of strain on LiveJournal's system to repopulate all that data, which is why use of it is restricted to SHes. However, if you're an interim, and you think a problem may be due to memcache, please IC and explain why you think this; just because you can't run the tool yourself doesn't mean you can't help out, and SHes aren't all-knowing. This tool also isn't perfect; it purges most things, but not every single conceivable memcached thing attached to a user. So if you don't notice any change in the user's journal after purging (and you've cleared your browser cache), it didn't do what you wanted.

RT, or Request Tracker, is the system which LiveJournal uses to track work internally. It is, therefore, the system into which bugs are posted for the developers to work on once we have diagnosed them.

This post is not intended to be an in-depth RT guide, just a list of tips on how to do what you need to do in RT as a support volunteer. If you've found any tricks that you think would be useful for your fellow volunteers to know, please comment with them and we'll see about putting them in the entry. Before we go any further, some terminology: a ticket is RT's name for what we call a request in Support, and a queue is much like a support category; it's a way of grouping tickets and keeping them organized. The only queue that we as Web volunteers are generally concerned with, and the only one addressed in this guide, is the "Bugs" queue, which, unsurprisingly, holds bugs.

The first thing you need to do with RT is log in. Visit http://rt.livejournal.org/ and log in using OpenID, with your journal's URL (e.g. http://exampleusername.livejournal.com) as your username. If it is your first time there, you will be asked for confirmation from LJ that you really wish to log in to the service. You will then be brought to a profile page; fill out your name and language in the appropriate fields. Use your @livejournal.com e-mail address in the e-mail field. Fill out anything else you want, although keep in mind that this stuff is publicly available, so you might not want your phone number in there. Once you have saved your profile, click on the "Home" link in the left-hand menu.

The first page you will see in RT proper is the "RT at a glance" page, which has a list of tickets you own (which will be empty except in very special cases), a list of the newest unowned tickets, and a list of queues that you can search. Now, you're probably here to either check on a bug or file one. In the latter case, you need to search first anyway, since we don't want duplicates, so let's talk about searching.

In most cases, you can find what you need by using the search box in the upper-right corner of the screen. Type appropriate words and phrases in there, like "client crashes in friends dialogue", and you will get tickets related to those. You may want to try a few variations - "browser crashes in friends dialogue" or "browser crashes on friends page", "I hate my life and want a cookie", etc. There is a more advanced search page, found by clicking on 'Tickets' in the left-hand menu, but it can be overwhelming the first few times you see it. If you decide to try it out, keep in mind that many things can be used as dates, including basic english phrases like "5 days ago" or "yesterday". (This is handy if you want to create a query for "all bugs made in the last five days", for instance.) This page will also let you save common queries, in case you're poking around in here for the same thing a lot. A more detailed, in-depth look at the search page is beyond the scope of this guide.

Once you've satisfied yourself that you want to open a new ticket, do so by using the "New ticket in" button on the top of the page. Here's how to file a ticket:

1. Set the drop-down next to the new ticket button to "Bugs" if that isn't already the value, then click it.
2. Leave the Status as "new" (because it is a new ticket). The status field lets you create tickets in other conditions, but you should never have a reason to do that.
3. Leave the Owner as "Nobody" unless you already know who your ticket needs to be assigned to. (If you're not sure, you don't know and shouldn't worry about it. The dev staff will assign unassigned tickets themselves.)
4. You will automatically be marked as a requestor if you filed the ticket; you don't have to add yourself to that field, but if there are others, insert their e-mail addresses here. Do not insert users who filed requests in Support that led to the ticket being created as requestors (or CCs or AdminCCs for that matter).
5. A CC is someone who needs to be kept up to date on developments in the ticket; you may fill in a list of e-mail addresses here. Generally speaking, you should not CC anyone on a request except other Support people who need to be kept up to date; always CC the Web administrator(s) and the Support Coordinator when filing a ticket from Web (or a ticket marked [web] from II), by entering their @livejournal.com addresses.
6. An AdminCC is someone who is actually working on the ticket, but isn't the owner. Leave this blank.
7. The Subject is a one-line summary of the problem you're reporting. It should be descriptive; think of every support request you've ever seen, then give your ticket a subject like the ones you always wanted the end users to use. If you're having trouble summarizing the issue, come back to this and fill it in after you write the description.
8. Leave the URL field blank. This may be used at some point, but currently is not.
9. The category is the general area of the site in which the bug occurs. Pick the closest one, or General/Unknown if nothing else seems to fit. Don't get too tied up on this if it's not clear where the ticket should go; that's why G/U is there.
10. The file attachment box is useful if you are sending a patch yourself, or other supporting files. If you aren't, leave it blank and don't worry about it.
11. The description should be brief and to-the-point. Describe the general issue and paste in links to any support requests you happen to know of that relate to it; it is not necessary to locate and obsessively link every request related to the issue; if the devs need more links than we provide, they'll ask for them.
12. You're done. Hit create.

You can view the ticket you've created (or any ticket) by going to http://rt.livejournal.org/Ticket/Display.html?id=[ticket number], e.g. http://rt.livejournal.org/Ticket/Display.html?id=1 - once there, you can append more information to a ticket. Please note: RT is not a place to discuss changes to LiveJournal. That is what suggestions is for. You should only append to a ticket if you have more information about the bug described in it, suggestions for implementation, etc. If that is the case, reply using the "Reply" link at the top of this page, and type your text in. This is not editable or removable in any way, so be careful what you say. When you're viewing a ticket, you may also use the ticket context menu which appears in the left-hand side to edit various parts of it; this is useful to add yourself to the CC list, for instance. Please do not CC yourself on an excessive number of tickets; if you're just interested in seeing what happens, go back and check later. Only CC yourself if you actually need to be notified immediately when the status of the ticket changes. Otherwise, make a custom search that includes those tickets and bookmark it.

That's about it for the introduction. If you want more information on RT, try http://wiki.bestpractical.com/ and http://wiki.bestpractical.com/index.cgi?UserManual in particular.

What is a login, anyway?

Login is the term used to describe the process of using your username and password to prove your identity to a service, particularly to begin a series of communications with that service that will not require you to enter your username and password with every transaction.

This all sounds great. So what's the problem?

There are several kinds of login problems, some of which fall into the Web Interface category and some of which are really General/Unknown material:

The most common login problem is that the user is simply entering the wrong password. This may be occurring because the user has mistyped it, or does not really know it, or accidentally left the caps-lock key on. This is a gunk problem, and will generally be resolved in that category.

Login problems may also be caused by incomplete support for JavaScript in the user's browser. LiveJournal uses JavaScript to protect the password so that it cannot be intercepted between the user's computer and LiveJournal's server, but this means that a browser that does not support JavaScript completely will have trouble logging in.

If the user is unable to properly accept cookies, a login may appear to succeed, but then the user may be immediately logged out when they visit any other page. More information on this problem is available in the cookies problem-solving guide.

Lastly, login problems may occur if the user's account has been deleted and purged. In this case, however, the user will be notified of this when they attempt to log in; receiving a request from such a user is a rare event. This type of request should also be answered in Gunk, as it does not involve an error in LiveJournal or in the user's browser.

So, to recap: Questions about "bad password" errors and purged accounts should be sent to gunk if they are seen in Web first, so that at least one attempt may be made there to correct for user error. Other error messages, or unresponsiveness on the part of the brower, are Web problems and should remain in Web.

So what can be done?

A user may request to be e-mailed a link which will allow them to reset their password as described in the lost username/password FAQ.

If the issues are JavaScript-based, the user may enable JavaScript, add livejournal.com and theirusername.livejournal.com to any in-browser security or trusted site lists, and alter settings in their browsers which selectively disable JavaScript.

There is a FAQ that addresses all of these possibilities, and it should be referenced on any request that seems to be a login problem.

How can I tell if something is a login problem?

Generally diagnosis of login problems is relatively straightforward, since the user will be sent an error message explaining that they have failed to log in. In most cases the user will report this fact in the request.

How Web Assigns Privs

The following information represents the guidelines that Web uses to assign our privileges. Please note that these requirements are not entirely absolute; skill in one area may compensate for missing skills in other areas, and no-one knows or is expected to know everything about every feature or type of problem.

Interim 1

To earn I1, a volunteer must demonstrate the following:

• Knowledge of the issues described in the Basic Issues section of this documentation and the correct way to solve each of them.
• Decent Support writing style.
• Maturity and apparent ability to handle private information.

The I1 package in web includes the supportviewscreened and supportmakeinternal privs (which allow one to view screened answers and make internal comments, respectively), as do I1 packages in other categories. Web also gives the supportviewinternal priv with I1, however, which allows volunteers to see internal comments in the Web category. For that reason, I1 will not generally be issued in Web until the user has demonstrated an advanced level of maturity and/or ability to keep confidential information confidential (usually by having at least I1 for some time in another category, although that is not the only way).

Interim 2

To earn I2, a volunteer must demonstrate the following:

• Knowledge of the issues described in the Intermediate Issues section of this documentation and the correct way to solve each of them.
• Solid Support writing style.
• Willingness to answer requests that involve more than a basic FAQ reference.
• Interest in and at least some ability for doing troubleshooting work with users.
• Knowledge of when it is appropriate to use ICs, and ability to participate in IC conversations in requests.

The I2 package in Web includes only the supportmovetouch privilege, which allows a volunteer to move requests out of Web and to remove them from or add them to the green queue. Nevertheless, it symbolizes a large step towards Supporthelp; in some ways, a movement to I2 in Web can be more difficult than in other categories, because you must demonstrate your ability to successfully use all three of the privileges you have been given.

Interim 3

To be eligible for I3, a volunteer must demonstrate the following:

• Knowledge of the issues described in the Advanced Issues section of this documentation and the correct way to solve each of them.
• Exemplary Support writing style.
• Ability to answer requests that involve more than a basic FAQ reference with a high degree of accuracy.
• Well-developed troubleshooting ability.
• Knowledge of which requests should be removed from Web or dequeued.
• Patience.

Because of the difference in nature between Web and other Support categories, most volunteers advancing to supporthelp will be asked to priv-play; that is, to go through the interim 3 level. I3s in Web must demonstrate that they are capable of performing every task expected of a Supporthelp, with the exception of approvals (since that is, of course, what priv-play itself is supposed to demonstrate).

As with all other categories, it is expected that the step from I2 to I3 will take a much longer time than any other transition in Support. If you have been an I2 for a long time and are beginning to feel discouraged, don't worry; that's entirely normal. Please feel free to contact the Web administrators if you have any concerns about your advancement in the category, or if you just want to talk about how you're doing (or vent your frustrations).

Supporthelp

To earn SH, a volunteer must demonstrate the following:

• Knowledge of which answers are approvable.
• Knowledge of what makes an answer shiny instead of merely approvable.
• Knowledge of one's own limits; that is, which requests to leave alone.

A web SH, in addition to the supporthelp priv, gains the ability to do a memcache purge. A Web supporthelp may also take part in the reviewing process. Please contact the Web administrator if you wish to do reviews as a new supporthelp and need some help getting started.

What exactly do you mean by "navigation" here?

The action buttons attached to the different LiveJournal forms. The "Login" button, for instance, and the "Update Journal" button. Also, the drop-down menus used in certain LiveJournal layouts (for instance, the 'Update' item that appears under the 'Journal' item in XColibur).

What kind of problems might we see with the navigation on LiveJournal? How can they be fixed?

The navigation might not be appearing for the user, or might not be activated when the user clicks on it or hits return in an appropriate form. Both of these problems are generally caused by incomplete JavaScript support in the user's browser. This can happen if the user's browser is out of date, if its basic support for JavaScript is not particularly good to begin with, or if the user has used built-in options, plugins, or extensions to disable some pieces of JavaScript. (Many users do this to protect themselves from unwanted advertisements and other annoyances, and many others enable or disable such features accidentally.)

In this case, the solution is to upgrade one's browser, unselect any options that selectively disable JavaScript, add LiveJournal to any "trusted site" list that may exist to allow it to use JavaScript, or use a new browser. The "Navigation" section of FAQ 210, "Why does LiveJournal display incorrectly in my browser?" is specifically designed to deal with problems like this, and an answer to a question about missing buttons or unusable navigation should reference it.

What are some common signs of navigation problems?

• The user reports that there are no buttons on any LiveJournal form (the "Update Journal" form, for instance, or the login form).
• The user reports that there are no menu options on the main page under "Journal", "Customize", etc.
• The user reports that clicking a button, such as the "Update Journal" button, doesn't do anything.

What is a cache, anyway? Can I spend it?

A cache is a copy of some or all of the files from an internet site that your browser downloads when you visit that site. If you return there within a certain period of time, the browser displays the copies instead of going to the site again to retrieve the files, which speeds up your browsing and saves bandwidth for both you and the host in question.

Generally, a server will tell the browser how long a particular file should stay in the browser's cache for. Some files, such as the main search form for Google, are unlikely to change over the course of the day. Others, such as the evil overlord list, are unlikely to ever change. And still others, such as most pages on LiveJournal, are expected to change virtually every time you view them. In each case, the server will instruct the browser to only hold onto the file for the appropriate amount of time, so that the user never (or rarely) sees an out-of-date version of the file. Further, when the browser does ask for a new copy, it can ask only for information about the file (such as the time it was last updated) rather than the file itself, and compare that time to the last time it retrieved it, to avoid having to download the file again if it hasn't changed.

This all sounds great. So what's the problem?

The problem is that certain "browsers" tend to ignore the information that the server sends about how long a page should stay in cache for, and cache it for as long as they feel like caching it. Further, most browsers contain user-settable options that can override the server's settings for how long something should stay in cache. In either case, a user can be left seeing an old version of the page instead of the one that's currently on the server.

So what can be done?

There are some helpful howto tutorials which explain how to clear out the cache files in many browsers. Clearing these files will allow the user to see the most recent version of the page, and hopefully get around whatever problem they're currently experiencing. There is also a FAQ which addresses specifically this issue. The FAQ should be referenced in any cache-related answer; one should only link directly to the tutorials in cases where the user has somehow missed them in the FAQ, or other similarly unlikely circumstances.

How can I tell if something is a cache problem?

Here are some common signs of cache problems:

• The user reports that their friends page or journal isn't taking updates when they know updates have occurred, particularly if you can see updates that they don't seem to be able to.
• The user reports that the "Update Journal" link on the LiveJournal home page takes them straight to the results page (the one containing links to memorify or view the updated entry).
• The user sees information that should only be visible while logged in even after logging out, or cannot see information that should be visible after logging in.
• The user receives an error about the page being too old when attempting to log in.
• The user has received e-mail notifications of comments on a journal entry, but can't see them through the web interface.
• The user reports that something is behaving in a way which is not consistent with recent patches. For instance, the user may not be able to see newly-added elements on the comment interface.

Please be aware that this isn't an exhaustive list. Caching can cause many different kinds of errors, and diagnosing some of them may require some detective work. In fact, if you encounter some kind of strange problem, one of the first questions you should ask yourself is: how could caching cause this? You won't always find a solution that way, but cache problems will be a consistent nemesis for you as you continue your work in Web, and it's best to begin learning to hate them early.

The Interface that can be seen is not the true Interface.
The URL that can be found is not the true URL.

Getting started in the Web Interface category is easier than you think.

Web Interface is the category that deals with problems the user has accessing the main interface for the LiveJournal web site. If a user sees an error message, that request belongs in Web. If a user experiences unexpected behavior from a feature, that request belongs in Web. If a user is reporting a bug, that request belongs in Web (for a while, at least).

Don't fear Web. Embrace it! You may not be a community maintainer, you may not run a client, you may not have developed a custom style, but you have used the web interface to access LiveJournal. You, too, have experienced some bizarre issue while trying to post an entry that you ended up fixing by metaphorically or literally jiggling the power switch on your computer. And, if you are the average support volunteer, someone in your family or one of your friends has probably called you up to ask you how to get "this internet thing" to work. All you're doing in Web is combining those three skills.

Because of the nature of Web, it is generally going to contain more bizarre requests than any other category. That is true. Nevertheless, there are simple, easy requests in Web, just as there are anywhere else, and the purpose of this guide is to show you what those are, and how knowledge of them can lead you into answering the more difficult requests that lie further down the board.