Welcome Guest Search | Active Topics | Sign In | Register

Custom headers are transmitted to resources Options
Ira Whitman
Posted: Wednesday, September 17, 2025 1:46:52 PM
Rank: Newbie
Groups: Member

Joined: 4/21/2022
Posts: 2
I encountered an error after upgrading from EO.WebBrowser 19.2.91 to 25.1.35. (Yep, it was a big jump.)
When loading page, https://login.epicor.com, several errors such as the follow were logged:

Quote:
GET https://ajax.aspnetcdn.com/ajax/jquery.validation.unobtrusive/4.0.0/jquery.validate.unobtrusive.min.js net::ERR_FAILED
Login:1 Access to script at 'https://ajax.aspnetcdn.com/ajax/bootstrap/4.4.1/bootstrap.min.js' from origin 'https://idp.developer.epicor.com' has been blocked by CORS policy: Request header field username is not allowed by Access-Control-Allow-Headers in preflight response.
Login:78


These scripts and a few css files at aspnetcdn.com are resources referenced by the page at login.epicor.com. I tracked the problem down to these lines of code
Code: C#
private void WebView_BeforeRequestLoad(object sender, BeforeRequestLoadEventArgs eventArgs)
        {
            var webView = (WebView)sender;
            eventArgs.Request.Headers[Constants.USERPREFS_UI_CULTURE_CODE] = CultureCode;
            eventArgs.Request.Headers[Constants.SOURCEHEADER] = Source;
            eventArgs.Request.Headers[Constants.USERNAME] = UserName;
            if (!String.IsNullOrEmpty(Error))
                eventArgs.Request.Headers[Constants.ERROR] = Error;
        }


Constants.USERNAME is equal to "username", which is reported in the error message, "Request header field username". The essential cause is that aspnetcdn.com does not allow these custom headers. Of course, have no control of server policies at aspnetcdn.com.

Using EO.WebBrowser 19.2.91, the custom headers added to the request to https://login.epicor.com were not transmitted to the resources (scripts and css) it references, but in the latest version(s) it does. I found no reference to anything like this in the change logs, so I don't know when it occurred.

Was this an intentional change?
Is there an option to have this behave as they did in 19.2?

I can "resolve" the issue by not applying the headers except that sometimes I need them.

Thank you
eo_support
Posted: Wednesday, September 17, 2025 2:58:33 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,410
Hi,

I believe the changes were due to BeforeRequestLoad were not fired for all requests in v19 but it is in v25. You can add code in BeforeRequestLoad to check the request (such as e.Request.Url or e.Request.RequestType) to skip the headers unless they are main resources.

Thanks!
Ira Whitman
Posted: Wednesday, September 17, 2025 3:19:21 PM
Rank: Newbie
Groups: Member

Joined: 4/21/2022
Posts: 2
Brilliant!

The addition of this if resolved my issue:
Code: C#
if (eventArgs.Request.ResourceType == ResourceType.MainFrame)
            {
                eventArgs.Request.Headers[Constants.USERPREFS_UI_CULTURE_CODE] = CultureCode;
                eventArgs.Request.Headers[Constants.SOURCEHEADER] = Source;
                eventArgs.Request.Headers[Constants.USERNAME] = UserName;
                if (!String.IsNullOrEmpty(Error))
                    eventArgs.Request.Headers[Constants.ERROR] = Error;
            }


Could you confirm filtering to ResourceType.MainFrame matches the 19.1 behavior?
eo_support
Posted: Wednesday, September 17, 2025 4:28:31 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,410
Hi,

Yes. That's correct.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.