ExamGuru IT/.Net Guru : HttpContext vs Page class? on ASPFriends.com 'aspngbeta' list

.NETGURU

HttpContext vs Page class?

Messages

Related Types

This message was discovered on ASPFriends.com 'aspngbeta' list.

Mark

I asked this question before, but I don't think anyone tackled it....

Anyway, my confusion is this: as far as I understand it, all pages are
derived from the System.Web.Ui.Page class, which provides our references to
built-in objects like Request, Response, and so on. But why do these same
objects turn up in HttpContext and in HttpApplication? Better yet, what is
the real meaning of HttpContext, as it doesn't seem to be directly
inherited/implemented by any other class?

If anyone can help me see the connection here, I would be very appreciative.
It might also help to know how the IHTTPHandler interface fits in.

Thanks,
M

Reply to this message...

Susan Warren

HttpContext.Current (the HttpContext for the current request) is
magically mapped to the Context property of Page and UserControl, as are
the Request, Response, etc, objects it exposes. This is pretty
convenient for pages, but missing if you need to get to the context from
the Global.asax or a middle tier object. So these classes use
HttpContent.Current to get to the context of the current request.

hth,
Susan

-----Original Message-----
From: Mark [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 02, 2001 11:47 AM
To: aspngbeta
Subject: [aspngbeta] HttpContext vs Page class??

I asked this question before, but I don't think anyone tackled it....

Anyway, my confusion is this: as far as I understand it, all pages are
derived from the System.Web.Ui.Page class, which provides our references
to
built-in objects like Request, Response, and so on. But why do these
same
objects turn up in HttpContext and in HttpApplication? Better yet, what
is
the real meaning of HttpContext, as it doesn't seem to be directly
inherited/implemented by any other class?

If anyone can help me see the connection here, I would be very
appreciative.
It might also help to know how the IHTTPHandler interface fits in.

Thanks,
M

| [aspngbeta] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspngbeta.asp =3D JOIN/QUIT

Reply to this message...

Stuart C. Salsbury

Page (because it derives from Control) provides a Context property that
returns an HttpContext. HttpApplication also provides a Context property
that returns an HttpContext.

I don't know of any difference between the objects returned by these
classes, but I could be missing something.

HttpContext is the class that provides the Request, Response, etc. objects
to the Page and HttpApplication objects. I think that the HttpContext
properties (Request, Response, etc.) are copied into the Page and
HttpApplication classes for our convenience and for backward
code-compatibility with ASP3.

--- --- --- ---

Regarding IHttpHandler, it is an interface that you implement when you want
to handle Http requests. Such a statement may be tautological, but the
question is, "why do I want to handle Http requests?". For us, the answer
has been, "because I want to have a runtime decision of which Page I want to
assign to handle any given URL".

Thus, I know that one way (among lots) that you can employ the IHttpHandler
interface is to map URLs to custom pages. For one example, you could define
a handler that looks at the URL of the request in order to determine which
class (inherited from Page) to assign the task of processing the request.
to do so, you could put the following in your config.web:

<httphandlers>
<add verb="*" path="*" type="MyNS.PageDispatch" validate="false" />
</httphandlers>

This fragment will tell the .net framework to assign the job for all
requests to a class named MyNS.PageDispatch, and (I think) not to worry
about whether or not the file exists. Note that for this to work the way we
wanted it to, the .NET framework has to be given a chance to choose among
all requests which ones it will process.

We've done this (in the brute force mindset) by assigning all URL requests
within our application space to the .NET framework. We do this in the IIS
properties.

In the App Mappings tab of the Application Configuration Window for a given
IIS app, we set:

Executable: C:\WINNT\Microsoft.NET\Framework\v1.0.2204\xspisapi.dll
Extension: *
Limit To: GET,HEAD,POST,DEBUG
Script engine: checked
Check that file exists: not checked

It is up to you to define a class that can dispatch all page requests to a
specific HttpHander (this class needs to implement IHttpHandler). Basiclly,
this interface is a way to standardize the delivery of the ProcessRequest
service.

In our use, we look at the URL that's been requested and decide what page to
assign the request to. Here's a digest of our implementation of the
ProcessRequest method (in PageDispatch.cs):

///note that in simplifying my code if edited and not checked, so there may
be problems here, but this is the idea

    public void ProcessRequest(HttpContext context)
    {
        Page myPage;

        if ( (string)(context.Application["matching_url"]) ==
(string)context.Request.Url)
        {
            myPage = new CustomPage1();
/// if it inherits from Page, then it will implement
/// IHttpHandler, and thus will support the Process request method
            myPage.ProcessRequest(context);
        }
        else
        {
            myPage = new CustomPage2();
            myPage.ProcessRequest(context);
        }
    }

Note that this technique is going to to hurt if you try to serve image files
or other staticky type pages out of it. We define a different config.web
that specifically removes our HttpHandler from the process in a /static
subdirectory of our web. The following is the entire config.web for our
static subdirectory.

<configuration>
<httphandlers>
<remove verb="*" path="*" type="MyNS.PageDispatch" validate="false" />
</httphandlers>
</configuration>

A faster way to do this for JPGs and other totally static things would be to
host them in an app that doesn't even consider the ASP.NET processor. As we
move toward deployment, we'll probably split our "static" pages into those
that are really static (gif, jpg, etc) and those that are just regular aspx
pages that skip the dynamic httphandler assignment routine (delivering pages
directly).

I'm sure there are many other uses for useful implementations of
IHttpHandler (HttpApplication and StaticFileHandler class both implement the
interface), but I haven't used them.

Regards,
Stuart Salsbury
Ernst & Young LLP

-----Original Message-----
From: Mark [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 02, 2001 2:47 PM
To: aspngbeta
Subject: [aspngbeta] HttpContext vs Page class??

I asked this question before, but I don't think anyone tackled it....

Anyway, my confusion is this: as far as I understand it, all pages are
derived from the System.Web.Ui.Page class, which provides our references to
built-in objects like Request, Response, and so on. But why do these same
objects turn up in HttpContext and in HttpApplication? Better yet, what is
the real meaning of HttpContext, as it doesn't seem to be directly
inherited/implemented by any other class?

If anyone can help me see the connection here, I would be very appreciative.
It might also help to know how the IHTTPHandler interface fits in.

Thanks,
M

Reply to this message...

Kamal Patel

Mark,

By definition "HttpContext is a class that encapsulates all HTTP-specific
information about an individual Http Request".

An HttpContext object is created when a request is made by any user agent
(browser). Here are some of the exposed by the HttpContext:

HttpContext:
- Application (HttpApplication class )
- Request (HttpRequest class)
- Response (HttpResponse class)
- Session (HttpSession class)

HttpContext only provides references to these objects. All of the above
objects (4 in this case) are provided by the HttpRuntime. The same
references are provided to the Page class, Application class, User Control
class etc.

When you call Response.Write() from your aspx Page it simply points to the
current HttpResponse.Write(). Also when you call
Page.Context.Response.Write() or Application.Context.Response.Write(), they
all point to the current HttResponse.Write().

Hope this helps,
Kamal

--
Kamal Patel
GoAmerica Communications

"Mark" <Click here to reveal e-mail address> wrote in message news:380259@aspngbeta...
[Original message clipped]

Reply to this message...

	System.Web.HttpApplication
	System.Web.HttpContext
	System.Web.HttpRequest
	System.Web.HttpResponse
	System.Web.HttpRuntime
	System.Web.IHttpHandler
	System.Web.UI.Page
	System.Web.UI.UserControl
	System.Windows.Forms.Application
	System.Windows.Forms.UserControl

ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification

Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews

.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT

Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project

FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.

Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials

	Copyright © ExamGuru, Inc. 2001-2006
	Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification