28,406
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
puregirl 2001-10-02
- 打赏
- 举报
Client Capabilities
One of the more significant design decisions you will make is how your application will handle differing client capabilities. For example, one of the most important issues for users is the speed of the connection. If your application can determine this speed, it can adjust the response to match that capacity. The only way for your application to be aware of the current connection speed is if the client includes this information as part of its request.
You can solve the client capabilities problem on either the client side or server side. The client-side solution relies on Dynamic HTML (DHTML) to include a description of the client's current configuration as part of the request, as depicted in the graphic below.
The benefits of this approach include:
Reduction in roundtrips between the client and server.
Reduced load on the server.
Improved application responsiveness due to proxy server caching technology.
There are some situations where client-side scripting will not be feasible. For example, applications that are exposed on the Internet cannot guarantee that the client will support scripting, which means the applications may fail for some clients. In addition, server-side resources may not be accessible from the client side, as the client may reside on a network that does not allow scripting for security reasons.
The server-side approach relies on the Browser Capabilities component. This component reads the User Agent HTTP header included with the request to determine the client's capabilities. The version of the Browser Capabilities component that shipped with IIS 3.0 and 4.0 determined client capabilities by looking them up in a static list. The following graphic shows the sequence of events.
This approach presented difficulties for application designers when the list became out of date. More importantly, this technique did not cover configurable aspects of a client's capabilities and did not provide a means of what was actually enabled at the time the request was made.
In IIS 5.0 the Browser Capabilities component has been improved to overcome these earlier design limitations. The Browser Capabilities component can now be modified for an individual request by the client returning a cookie describing its capabilities. In addition, if the initial request for an .asp file does not include a cookie, you can call back to a script that will run on the client to create the cookie. The following illustration shows the sequence of events.
This improvement to the Browser Capabilities component creates another alternative to the server-side solution. This technique uses a special status code to call back to the client when a request comes in that does not include a cookie. You can generate this status code by placing a special meta tag as the first line in your .asp file. For example:
<!-- METADATA TYPE="Cookie" NAME="BrowsCap" SRC="sendcook.htm" -->
instructs IIS to send the special status code—an HTTP 449 status code—to Internet Explorer 5.0; it then tells Internet Explorer 5.0 to run the script in Sendcook.htm, which will generate a cookie describing the client capabilities. When the server receives this cookie, it will use the cookie in conjunction with the Browser Capabilities component to determine how to send the response back to the client.
Important If the METADATA meta tag exists in a file that is requested by the client as a result of a redirection using the Server.Transfer or Server.Execute methods, IIS will ignore the meta tag. METADATA meta tags in the file that actually contains the redirect, however, will be processed normally.
For more details on how to use this feature, see Retrieving Browser Capabilities from a Cookie.
For more information on DHTML client capabilities, see the DHTML reference information on MSDN Online. The MSDN Online homepage is at http://msdn.microsoft.com/. For an example of the new Client Capabilities component functionality, see the Browser Capabilities Component and ASP Samples.
--------------------------------------------------------------------------------
© 1997-1999 Microsoft Corporation. All rights reserved.
今天过节酒喝多了,不知道上面的文字是不是你想要知道的,引自win2k的IIS5的帮助文档
http://192.168.0.11:6000/iishelp/iis/htm/asp/eadg6isz.htm
192.168.0.11:6000是我的机器的主机,换成你自己机器的IP吧,如果你没有什么改动的话
这样访问http://localhost/iishelp/iis/htm/asp/eadg6isz.htm
One of the more significant design decisions you will make is how your application will handle differing client capabilities. For example, one of the most important issues for users is the speed of the connection. If your application can determine this speed, it can adjust the response to match that capacity. The only way for your application to be aware of the current connection speed is if the client includes this information as part of its request.
You can solve the client capabilities problem on either the client side or server side. The client-side solution relies on Dynamic HTML (DHTML) to include a description of the client's current configuration as part of the request, as depicted in the graphic below.
The benefits of this approach include:
Reduction in roundtrips between the client and server.
Reduced load on the server.
Improved application responsiveness due to proxy server caching technology.
There are some situations where client-side scripting will not be feasible. For example, applications that are exposed on the Internet cannot guarantee that the client will support scripting, which means the applications may fail for some clients. In addition, server-side resources may not be accessible from the client side, as the client may reside on a network that does not allow scripting for security reasons.
The server-side approach relies on the Browser Capabilities component. This component reads the User Agent HTTP header included with the request to determine the client's capabilities. The version of the Browser Capabilities component that shipped with IIS 3.0 and 4.0 determined client capabilities by looking them up in a static list. The following graphic shows the sequence of events.
This approach presented difficulties for application designers when the list became out of date. More importantly, this technique did not cover configurable aspects of a client's capabilities and did not provide a means of what was actually enabled at the time the request was made.
In IIS 5.0 the Browser Capabilities component has been improved to overcome these earlier design limitations. The Browser Capabilities component can now be modified for an individual request by the client returning a cookie describing its capabilities. In addition, if the initial request for an .asp file does not include a cookie, you can call back to a script that will run on the client to create the cookie. The following illustration shows the sequence of events.
This improvement to the Browser Capabilities component creates another alternative to the server-side solution. This technique uses a special status code to call back to the client when a request comes in that does not include a cookie. You can generate this status code by placing a special meta tag as the first line in your .asp file. For example:
<!-- METADATA TYPE="Cookie" NAME="BrowsCap" SRC="sendcook.htm" -->
instructs IIS to send the special status code—an HTTP 449 status code—to Internet Explorer 5.0; it then tells Internet Explorer 5.0 to run the script in Sendcook.htm, which will generate a cookie describing the client capabilities. When the server receives this cookie, it will use the cookie in conjunction with the Browser Capabilities component to determine how to send the response back to the client.
Important If the METADATA meta tag exists in a file that is requested by the client as a result of a redirection using the Server.Transfer or Server.Execute methods, IIS will ignore the meta tag. METADATA meta tags in the file that actually contains the redirect, however, will be processed normally.
For more details on how to use this feature, see Retrieving Browser Capabilities from a Cookie.
For more information on DHTML client capabilities, see the DHTML reference information on MSDN Online. The MSDN Online homepage is at http://msdn.microsoft.com/. For an example of the new Client Capabilities component functionality, see the Browser Capabilities Component and ASP Samples.
--------------------------------------------------------------------------------
© 1997-1999 Microsoft Corporation. All rights reserved.
今天过节酒喝多了,不知道上面的文字是不是你想要知道的,引自win2k的IIS5的帮助文档
http://192.168.0.11:6000/iishelp/iis/htm/asp/eadg6isz.htm
192.168.0.11:6000是我的机器的主机,换成你自己机器的IP吧,如果你没有什么改动的话
这样访问http://localhost/iishelp/iis/htm/asp/eadg6isz.htm
talentboy 2001-10-02
- 打赏
- 举报
可以用JavaScript来实现。先得到客户端的分辨率，然后将这个值赋予一个隐含帧中的某个对象，然后将这些数据提交服务器端。
不过，你知道客户端的分辨率有什么用呢？
不过，你知道客户端的分辨率有什么用呢？
mimihuhu 2001-09-30
- 打赏
- 举报
恩，试过了，就这个
zoujian 2001-09-14
- 打赏
- 举报
javascript:screen.width,screen.height
lanying 2001-09-14
- 打赏
- 举报
to mimihuhu(迷糊)
好像没有吧？
好像没有吧？
mimihuhu 2001-09-14
- 打赏
- 举报
其实我是想问request.servervariables("http_")客户端信息里面可有参数用来取分辨率
安优小青和他的程序生活 2001-09-14
- 打赏
- 举报
activex控件下载到客户端，然后开始判断运行，最后传递给你的网页控制代码
安优小青和他的程序生活 2001-09-14
- 打赏
- 举报
只能利用activex技术
hulj 2001-09-14
- 打赏
- 举报
ASP是服务器端运行的，取不到客户端
