Theory
The server's side of the conversation
Every page view is a short conversation: the browser sends a request, and the server sends a response. You have been building the response all along (server controls render into it), but sometimes your code needs to speak to the browser directly, to send a quick message, or to redirect the visitor elsewhere.
ASP.NET gives you the Response object for exactly this: the outgoing half of the exchange. This lesson covers how your server code uses Response to communicate with the browser, and its incoming partner, Request.
Theory
The Response object
Response represents the reply your server is sending back to the browser. Its most useful members:
- Response.Write(text): writes text straight into the page output.
- Response.Redirect(url): tells the browser to go to a different page.
- Response.Cookies: attaches cookies to the response (small data stored in the browser).
Its partner is Request, the incoming data from the browser: Request.QueryString reads values from the URL, Request.Form reads submitted form fields, Request.Cookies reads cookies the browser sent. Request comes in; Response goes out.
Practical
Writing to the browser and redirecting
// Send text straight into the page
Response.Write("Welcome to FestConnect!");
// After a successful registration, send the student to a thank-you page
protected void btnRegister_Click(object sender, EventArgs e)
{
// ... save the registration ...
Response.Redirect("ThankYou.aspx"); // browser now requests ThankYou.aspx
}
// Read something the browser sent in (the incoming Request):
string eventId = Request.QueryString["eventId"]; // from a URL like ?eventId=12Formula
Request in, Response out
Hold on to this pairing. Request is everything the browser sent TO the server: the URL, query string, form fields, cookies. Response is everything the server sends BACK: the HTML, redirects, cookies to store.
Your code reads from Request to find out what the visitor wants, and writes to Response to reply. Every ASP.NET page sits between these two: incoming Request on one side, outgoing Response on the other.
Quiz
After a student registers, you want their browser to move to ThankYou.aspx. Which Response member do you use?
- Response.Write("ThankYou.aspx"), which navigates to the page
- Response.Redirect("ThankYou.aspx"), which tells the browser to request that page
- Request.QueryString["ThankYou.aspx"], which loads the page
- Response.Cookies, which redirects using a cookie
Show the answer
Response.Redirect("ThankYou.aspx"), which tells the browser to request that page
Response.Redirect(url) tells the browser to request a different page, which is exactly how you move the visitor to ThankYou.aspx. Option A is wrong: Response.Write just prints the text 'ThankYou.aspx' onto the current page; it does not navigate anywhere. Option C is wrong: Request.QueryString READS incoming values from the URL; it is part of the incoming Request, not a way to send the browser somewhere. Option D is wrong: Response.Cookies stores small data in the browser; it does not perform redirection. Remember the direction: to send the browser to a new page, use Response.Redirect.
Think first
Why redirect instead of just showing the thank-you content?
You could display the thank-you message right on the registration page. Why send a redirect to a separate page instead? Then tap.
Show the answer
The main reason is to avoid the DOUBLE-SUBMIT problem and give a clean URL. If you save the registration and then just show a thank-you message on the same page (which was reached by a POST), the browser still 'remembers' that it got here by submitting the form. If the student then refreshes, the browser re-submits the form, registering them a second time, and shows a scary 'resend form data?' prompt. Redirecting after a successful save (a pattern called Post-Redirect-Get) fixes this: once saved, you send the browser to ThankYou.aspx with a fresh GET request, so refreshing simply reloads the harmless thank-you page, never re-submitting. It also leaves the visitor on a sensible, bookmarkable URL rather than the form's. So redirecting is not just cosmetic; it prevents accidental duplicate actions and keeps navigation clean. Save, then redirect: a habit worth keeping.
Summary
Key takeaways
- Every page view is a Request (incoming, from the browser) and a Response (outgoing, from the server).
- The Response object is how your server code talks back to the browser.
- Response.Write sends text into the page; Response.Redirect sends the browser to another URL; Response.Cookies stores data in the browser.
- Its partner Request reads incoming data: Request.QueryString (URL values), Request.Form (submitted fields), Request.Cookies.
- Read from Request to learn what the visitor wants; write to Response to reply.
- After a successful action, redirecting (Post-Redirect-Get) avoids duplicate submissions on refresh and keeps a clean URL.
- Memory hook: Request in, Response out.