Link to home
Start Free TrialLog in
Avatar of jondrejik

asked on

IIS 6 404.2 1260 error - Will not access files or directories with ".com" in the path name

Hoping the community can help me out.   Have been tracking down an issue for 2 days and think I've narrowed it down to an IIS 404.2 1260 error but don't know how to fix.

First this used to work and has been working for 5+ years.   The issue started sometime in the last 30 days.   I've removed all MS updates over the last 45 days to see if that was the issue but the problem still exists.

This is on a W2K3 server with IIS 6.  In the web service extentions the following are allowed... ASP, ASP .NET v 1.1.4322, ASP .NET v2.0.50727, PHP.   All others listed are prohibited.

We have a client based application that posts and gets files from a webserver.   The clients have a unique identification account name.   The clients who used their email address as their account names are failing to get files.   They can post files with no issues.   Clients that don't have a ".com" in their account name are working fine for both post and get.

I enabled the ability to surf the directory structure via https based URLs.   Walking the directory structure gives the same results as the client based application.  Here are examples.  For the ones listed as working I am able to access the directory and view the test.log file within the directory.  

Works -
Bad  -
Works -
Works -

For the one that is bad I get the following msg in the browswer..
       The page cannot be found
       The page you are looking for might have been removed, had its name changed, or is             temporarily unavailable.

Within the IIS logs I get the following for the working test accounts..200 0 0....

2013-01-05 02:24:25 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att-com/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C; +InfoPath.3;+.NET4.0E;+McAfee) __utma=13921579.1358780122.1345999780.1357314349.1357350449.12;+__utmz=13921579.1355368330.7.2.utmccn=(referral)||utmcct=/|utmcmd=referral;+__utmc=13921579 200 0 0 547 818 31

2013-01-05 02:24:31 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.com_/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0;
+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C; +InfoPath.3;+.NET4.0E;+McAfee) __utma=13921579.1358780122.1345999780.1357314349.1357350449.12;+__utmz=13921579.1355368330.7.2.utmccn= (referral)||utmcct=/|utmcmd=referral;+__utmc=13921579 200 0 0 550 819 15

2013-01-05 02:24:34 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows
+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+InfoPath.3;+.NET4.0E;+McAfee) __utma=13921579.1358780122.1345999780.1357314349.1357350449.12;+__utmz=13921579.1355368330.7.2.utmccn=(referral)||utmcct=/|utmcmd=referral;+__utmc=13921579 200 0 0 547 818 31

For the bad test account I get this in the iis log...404 2 1260....

2013-01-05 02:24:28 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+8.0;
+Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+InfoPath.3;+.NET4.0E;+McAfee) __utma=13921579.1358780122.1345999780.1357314349.1357350449.12;+__utmz=13921579.1355368330.7.2.utmccn=(referral)||utmcct=/|utmcmd=referral;+__utmc=13921579 404 2 1260 1795 818 0

For a production client that fails I get the same error in the iislog.....404 2 1260....

2013-01-05 02:00:40 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/22/ - 443 - X.X.X.82 HTTP/1.1 buddy+Client/2.00.0412 - - 404 2 1260 1795 228 0

I've tried to add .com as a new web svc extension and link it to the v2.0.50727/aspnet_isapi.dll but it tells me that already exists.   Adding .com as a new mime type of text/text has no impact.

Help.   I need some ideas for how to get this working again.  

Thanks  in advance for any support!!!
Avatar of Dave Baldwin
Dave Baldwin
Flag of United States of America image

Do you have anti-virus on the server?  I ask because it might think that '.com' is an attempt to do a redirect.  And that might have happened during an anti-virus update.

Also does it work on the server itself?
Avatar of jondrejik


Yes all the files can be accessed directly via windows explorer on the server and from another PC over the network.

There is currently no anti-virus on the server
These are identical!

Works -
Bad     -

Open in new window

xxx/bb/0/ is exactly the same...


Open in new window

I meant does that form of the URL with '.com' work internally in a browser at all.  We've had some questions where a content filtering or external firewall device got updated and blocked things that weren't expected.

The first two are not identical.   Slight difference is att-com .vs.   The att-com url works but the url fails.

Yes the file exists in your second question.   I can look at it via explorer.

Dave -  No the '.com' version does not work from a browser on the server and neither does one of the working test accounts...interesting   Can't access either from a browser on the server.   I am testing from a remote client PC and that can access all but the .com based accounts.

How do you check content filtering on the server?   There are no external devices filtering.
IE occasionally does some funny things to URLs.  Can you use an alternate browser on the server to check the URL?
If run from a browser on the server.....

IE gives me - IE cannot disply the webpage

Firefox gives me - You are not authorized to view this page

From a PC accessing the website IE works except for the accounts with .com in their name

Would upgrading to .net 4 make any difference?
I doubt it.  You need to use a network monitor like Wireshark to see what is actually being requested and responded.  It's starting to sound like a problem with the server's response but you need to verify what being requested to make sure.

Can you create a different sub-directory with plain index.html that uses the same URL pattern but won't go thru your ASP.NET code?  The purpose is to detect whether it is a server or code problem.
I created two test directories on each side of the webserver (http & https).   These test directories are on the server in the top level wwwroot directory.


Works =
Works =
Works =

Works =
Works =
Bad =

This shows a similar behavior where the customers posting with ".com" in their account names fails.   In previous posts I had not checked the simple test on the non-secure side of the site.   Based on these tests it looks like the secure side is having the issue.

I loaded WireShark but don't know enough yet to see if it is showing the error of the https traffice in the logs.   Will it show https errors or not?
You have to tell Wireshark to show HTTPS info, it doesn't do it by default.  It is probably a pain.

What error message do you get besides 404?
Already went thru that MS site.   This is likely what is happening but I can't figure out how to make ".com" part of the authorized ISAPI.   When I tried to add it as a mime type I got an error msg when I tried to save saying .com was already and authorized type.

Looking into wireshark

You shouldn't be adding it as a MIME type, it's just part of the URL, not a file or file type of it's own.  Do you have redirect code working on that server?  Just one more place that it could be misidentified.

Also, have you tried a URL other than ''?  Like
No redirects.

the google test has the same results.   Does not work on the secure side.
Do you get the exact same results in the log for these new errors?
I tried the experiment on an IIS 7.0 server and it worked fine with both HTTP and HTTPS.  I don't have access to an IIS6 server with HTTPS that I can try.
Yes same info in the logs  404 2 1260

Is there a way to reinstall a webserver on the same server and keep all the key settings?

Is there a way to export the settings so I could build a new one from scratch and then import the settings?
I don't know the answers to those questions.  I would not reinstall over your current web server since it is basically working except for this one thing.  I did read that you could import the 'metabase' from IIS6 but I don't know if that is everything.

Since apparently everything else works, you would be better off at this time to require the users to use something other than a decimal point in the directory / user names.
I recreated a new VM and redid the webserver from scratch.  I then ported over the settings screen by screen.   Net result is some improvement.  

Works - - Same as WS001
Works -  - Does not work on WS001
Bad - - Same as 001
Works - - Does not work on 001

The .com based accounts work on the local servers hard drive on both http and https.   This improves over the production WS001 since these did not work on https.

On the production NAS box attached to the webserver where the files are stored it did not work on the https side of the webserver so that was consistent with the production webserver.

If I could get the https gets working all would be well.   The https posts work just fine to the same directories.   This is what I can't understand... why do posts work but gets don't for the .com based accounts.

Any thoughts?
I don't know at this point.  Click on "Request Attention" above and get some others to look at this.
I don't have a setup like this one, but one thing which you haven't mentioned:
In IIS (and other servers) https goes to a single container.  There's only 1 listener for the https requests.  It has the 1 certificate you have for the server.

IIS does not care what the domain is with the request.  If you have 2 domains

but your cert is for, then even if the url is for
IIS will answer from the listener, because that's what is listening on 443.

So, if your urls work on, but not on, you'll get weird errors for a 443 (https) request even if you think you have said .
Only one server and it has port 80 and 443 open.  This server has the only certificat for the domain.

What fails are https gets to any account that has ".com" in the account name.  The accounts fail regardless of if they are stored on the drive in the server or on the NAS box.   This has been working for 5 years but stopped working after Oct 29th as that is the last successful set of transactions.  

All other accounts without ".com" in the account name remain fully fuctional.

I am clueless on the issue or how to resolve  at this point.
I understand that you have 1 server.  What I wondered was if you had 2 domain names identified in IIS.  Perhaps you don't -- it was just a thought.

I googled your error message, and the following discussion sounds like a possible workaround:

You change your configuration to allow the ccmisapi.dll ?  The discussion is about IIS7, but sometimes Windows OS updates include changes which affect IIS in all its versions.

In any case, it sounds as if a rule changed for your IIS which is no longer allowing a url rewrite you have for the user login as part of the url.
I tried to make this change but no luck.   IIS6 doesn't have the config file so no way to edit it.  I searched the server several times for something similar but no luck.  

In looking at the inetsrv directory the last file updated was 6/28/2010 other than the MetaBase.xml which was updated today.

The error from my webserver log looks like this for an active account...

2013-01-08 05:06:40 W3SVC2018762905 WCIWS-001 GET /bb/0/ - 443 - HTTP/1.1 buddy+Client/2.00.0403 - - 404 2 1260 1795 227 0

Agree something changed after Oct 29 that is preventing Get only on accounts with ".com".

Other thoughts or recommendations?

In reading the link there is also a discusion about remove / reinstalling "DP".   What is DP?
Is there an update?   Anyone have any ideas?
Avatar of mrcoffee365
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial