IE6 HTTP Bug with HTTP_Accept request header

Something I bumped into today: The first time Internet Explorer loads a URL, it sends an “HTTP_Accept” request header with the list of MIME types it accepts, like so:
HTTP_ACCEPT = application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Any subsequent request of the same URL, though, only sends “*/*”:
HTTP_ACCEPT = */*

Of course I watched this through an ASP page which wrote out Request.ServerVariables("HTTP_Accept").  I wasn’t sure if it was IIS or IE‘s fault tho, so I checked the raw headers with Fiddler, and it’s definitely IE.

What’s especially strange is that I can find little or no mention of the problem. Anyone else heard of (or conquered) this?

It rather messes up a page I’m working on…

UPDATE: See here for a bug and workaround demo article I just put together.

I haven’t changed any hardware in over 6 months,

…yet I got this message when I logged in today:

—————————
Windows Product Activation
—————————
Since Windows was first activated on this computer, the hardware on the computer has changed significantly. Due to these changes, Windows must be reactivated within 3 days.
Do you want to reactivate Windows now?

—————————
Yes No
—————————

Very strange. Any ideas?

(Tip: you can capture the text of many Windows dialogs into the clipboard by pressing Control-C while viewing them. The above example came that way. Couldn’t use printscreen while logging in, tho, or I’d’ve shown the dialog too.)

Two Solutions: ASP.net Framework 2.0 deployment woes

I recently deployed the ASP.net 2.0 Framework to my server, and since have been fighting with problems it’s caused. For instance, when I switched one app to use it, it broke all the other v1.1 web apps I was running (including this blog). Fortunately for me, someone else has been having the same problem and found a solution: move the 2.0 apps into their own application pool. Hooray I don’t have to uninstall (which I was close to doing).

Hey Microsoft, how about mentioning this anywhere? …say during the install, on the IIS site’s ASP.net tab, or in the error?

I have another related woe, though: If I set a 1.1 app to run under the 2.0 Framework (which should work, and imparts better performance and security), I get the ASP.net Yellow Screen of Death:

Apparently “global” now a reserved keyword under 2.0 (despite its 1.1 compatibility). Fortunately, I found my own easy fix: just rename the class. So line 11 in my global.asax.vb is now Public Class Global2. Of course I made the same change in its global.asax too: <%@ Application src="Global.asax.vb" Inherits="Global2" %>

Happy to find a solution, and I hope mine helps someone.

2005-10-01 – IPBOOTB errors

Problem:

My SBS 2003 box was getting this error several times a day:
“IPBOOTP was unable to receive an incoming message on the local interface with IP address x.x.x.x . The data is the error code.”

Process:

Most applicable suggestions I found said to either disable the DHCP Relay Agent service, or install a Win2000 hotfix.  No luck for me, though, since the service wasn’t installed, and I’m on SBS 2003.

Solution:

Microsoft.Public Usenet – IPBOOTP ERROR PLEASE HELP.  Hurrah, disabling DHCP Relay on the LAN interface in RRAS manager.

Another SBS SP1 hangup

I upgraded another client’s SBS 2003 machine to SP1 this past weekend.  It went remarkably smoothly, but we forgot to check their smartphones’ access to Exchange til today.  No connection, we checked the /OMA virtual directory, and got this error:

“A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.”

Much “jiggling” (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer.  I did see this error in the Application Log, though:

An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
   at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
   at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
EventMessage: 
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
   at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
   at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
   at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
   at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

What a mess.  But I recognized that “(403) Forbidden” as a web server error (although not on the actual OMA directory).  Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory’s settings, and aha! it was denying access to all IP addresses except 127.0.0.1 and one we don’t use.  It was not making an exception for the primary local address.  So I added that and all’s now good.

So when you’re having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.

Lesson learned.

Update 2008-11-07:
Ha!  I was troubleshooting for a customer, and found my own post (top of the google to ya, 3 years later!)  It wasn’t the same issue, but it was similar enough to set me on
the right track.