Re: Invalid http request for .NET control

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Mark Travis (mtravis_at_sysdel.skmconsulting.com)
Date: 08/23/04 

Date: Mon, 23 Aug 2004 14:55:30 +1000

Hi Peter,

Did some further testing as per your request. My initial testing was all
done via local host so I was able to bypass you request for local machine to
exclude DNS and proxies. I had the same problems off local host as servers.

Regarding the IP Address. I ran a couple of tests and found that the problem
still existed. However, the invalid requests were using the host name
instead of the IP Address. I believe this implies that the browser is
looking for the control on the server that the page was served from, and not
the server I specify in the object tag (I am currently running the control
and the referring page on the same server but in different virtual
directories).

After rereading the article which was a redirect from your first reply
        http://msdn.microsoft.com/msdnmag/issues/02/01/userctrl/
I tried to put the control in the same virtual directory as the page.
Although this did not remove the invalid requests, a valid request did occur
and it occurred as the first request for the control (ie the first request
found the control and downloaded it. It was then followed by 'x' invalid
requests for the control).

Note: On further review of my original testing, when the invalid requests
occur, no valid request was made for the control. Successful display of the
page was due to a locally cached version of the control. In the scenario
where there is no locally cached version of the control, no invalid requests
were made (only valid, requests were made).

Now, I also noticed that my test came back with less invalid requests than
my actual application, so I started to reduce the name of the component and
control. Originally the classid of the object was

http://localhost/SKM.IE.Wrappers/SKM.IE.Wrappers.Systems.DLL#SKM.IE.Wrappers.Systems.Browser
At the end of my testing I had
        Wrappers.DLL#Browser
as the component now resided in the same virtual directory as the page. This
again did not reduce the number of invalid requests but it did show up
something unusual. Because I had renamed the dll to Wrappers.DLL, all the
invalid requests referred to the original name of the dll (either internal
dll name or something else in the dll's meta data). When I recompiled the
component to Wrappers.DLL, the invalid requests referred to Wrappers not
SKM.IE.Wrappers.Systems.

My last test was to copy the component into the root directory of the Web
Server (as the first invalid request points there). This sort of fixes the
problem. When I check to the http traffic, there is now 2 requests for the
dll and both are valid and processed but it doesn't feel like the right
solution. I would have thought that I should be able to publish the
component in a virtual directory of my own choosing. Anyway, it still makes
2 requests and if the localcache is clear, it downloads both dll's, one from
the virtual directory and one from the root directory.

I hope this helps with your research

As a postscript, I have also noticed an invalid request for a file called
IEXPLORE.EXE.config. The following article

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/sidexsidenet.asp
states that IExplore uses this file to verify the version of the .NET
framework to use when running the control. If it does not find it, it will
use the latest .NET framework installed on the machine. I don't see this as
a problem. I have added it as an extraneous piece of information that is
related to this issue.

Thanks again

Mark

""Peter Huang"" <v-phuang@online.microsoft.com> wrote in message
news:C7L5qfphEHA.1556@cpmsftngxa10.phx.gbl...
> Hi Mark,
>
> Now I am researching the problem, but to isolate the problem, you may try
> to deploy the control on the localmachine to exclude the DNS and proxy
side
> effect. Also you may try to use the ip address to locate the assembly to
> see if this help you.
>
> Best regards,
>
> Peter Huang
> Microsoft Online Partner Support
>
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>

Relevant Pages

  • Re: dm-ioband + bio-cgroup benchmarks
    ... I have got excellent results of dm-ioband, that controls the disk I/O ... bandwidth even when it accepts delayed write requests. ... every device we want to control using rules. ...
    (Linux-Kernel)
  • Re: dm-ioband + bio-cgroup benchmarks
    ... I have got excellent results of dm-ioband, ... bandwidth even when it accepts delayed write requests. ... This will provide us the control of releasing ...
    (Linux-Kernel)
  • Re: [PATCH 1/9] io-throttle documentation
    ... +the page cache are processed asynchronously by kernel threads (pdflush), ... all the write-back requests that are not directly submitted by ... should be able to provide max bw control at IO scheduler level (along ... scheduler in the elevator, when the IO requests are submitted. ...
    (Linux-Kernel)
  • Re: [PATCH 1/9] io-throttle documentation
    ... +the page cache are processed asynchronously by kernel threads (pdflush), ... +cannot throttle the current task in this stage, because, in general, it is a ... all the write-back requests that are not directly submitted by ... should be able to provide max bw control at IO scheduler level (along ...
    (Linux-Kernel)
  • Re: dm-ioband + bio-cgroup benchmarks
    ... I have got excellent results of dm-ioband, ... bandwidth even when it accepts delayed write requests. ... This will provide us the control of releasing ...
    (Linux-Kernel)