Minh T. Nguyen

# re: Whidbey's Client Callback Feature on DotNetJunkies

Congratulations Minh!

Glad to help out.

# re: Whidbey's Client Callback Feature on DotNetJunkies

Can you comment on the suitability of Client Callback for real 'Internet' web solutions?

From what I can see, the feature is IE specific on the PDC and CTP versions of ASP.NET 2.0.

I read that Mozilla has support for 'XML http request objects' (see
http://webfx.eae.net/dhtml/xmlextras/xmlextras.html) but the javascript injected by ASP.NET is IE specific.

Do you know of any plan for cross browser support?

Marcus

# re: Whidbey's Client Callback Feature on DotNetJunkies

Marcus,

Sorry for the soo late reply.

This feature is ASP.NET 2.0 specific, yes. It's a new ASP.NET 2.0 feature. However, it should work on any browser that can instantiate the XMLHTTP object. This includes all major versions of IE and possibly other browsers such as Netscape as well. However, I have not done these test yet, and will do so. I will let you know here.
In addition, the Request.Browser object will tell you whether the browser supports Callback or not.

Hope this helps,
Minh T. Nguyen (again, I will try out Mozilla and Mac IEs as well some day).

# re: Whidbey's Client Callback Feature on DotNetJunkies

Good job, Minh!

# re: din seria ASP.NET 2.0

# re: Client Callbacks with ASP.NET 2.0

# re: din seria ASP.NET 2.0

# re: Client Callbacks with ASP.NET 2.0

# re: Whidbey's Client Callback Feature on DotNetJunkies

I implemented the callback example, and it works great in IE. However in Mozilla it chokes with an error

Error: pageUrl is not defined
Source File: http://localhost:35084/PlayWithAspCallBackFeature/WebResource.axd?a=s&r=WebForms.js&t=632248968185287500
Line: 53

Here is the line of code from the .axd file that asp.net is automatically generating.

if (pageUrl.indexOf("?") != -1) {
xmlRequest.open("GET", pageUrl + "&" + postData, false);
}

An idea how to get around this??

Also their is another error on the page in mozilla, that shows up in the javascript console but not to the user. Don't know if that has anything to do with it.

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getAnyTransferData]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/nsTransferable.js :: anonymous :: line 132" data: no]

Any ideas??
Thanks
Ashish

# re: Whidbey's Client Callback Feature on DotNetJunkies

Do you know if there need to be any special permissions set for this feature to work?
Because it works fine on my local server (WinXP, IIS 5.1) but returns javascript errors related to webresource.axd loading webforms.js and scripts for validation controls when put on production server (Win2k server, IIS 5.0).

Any suggestions?

# ASP.NET 2.0 and Cross Browser Support

Scott Guthrie talks about cross browser support in ASP.NET 2.0, but is the new Client Callback fixed?

# ASP.NET 2.0 and Cross Browser Support

Scott Guthrie talks about cross browser support in ASP.NET 2.0, but is the new Client Callback fixed?

# re: Whidbey's Client Callback Feature on DotNetJunkies

Sorry for the long wait guys. I haven't played with Mozilla and FireFox yet, so I don't know if it works for those browsers. However, the code that I wrote was using a relatively "old" version of .NET 2.0. Let's wait until .NET 2.0 is actually released. I am sure until then there will be a lot of changes in regards to this.

Thanks,
Minh T. Nguyen.

# re: Whidbey's Client Callback Feature on DotNetJunkies

This is tragic.
Microsoft, just read http://jibbering.com/2002/4/httprequest.html,
you dunces. Please don't expect other browser vendors to start supporting sicko activex methods of instantiation.

# re: Whidbey's Client Callback Feature on DotNetJunkies

There is one gotcha though. By default, ASP.NET 2.0 thinks Mozilla doesn't support callbacks/xmlhttp. The truth is that it can handle this stuff perfectly. To tell ASP.NET that Mozilla based browsers do support this stuff, we have to extend the configuration of the webapplication (either your web.config or the machine.config):



<browserCaps>
<!-- GECKO Based Browsers (Netscape 6+, Mozilla/Firebird, ...) //-->
<case match="^Mozilla/5\.0 \([^)]*\) (Gecko/[-\d]+)? (?'type'[^/\d]*)([\d]*)/(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters'\w*)).*">
browser=Gecko
type=${type}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
supportsXmlHttp=true
supportsCallback=true
<case match="rv:(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters'\w*))">
version=${version}
majorversion=${major}
minorversion=${minor}
<case match="^b" with="${letters}">
beta=true
</case>
</case>
</case>
</browserCaps>

# re: Whidbey's Client Callback Feature on DotNetJunkies

I have the same issue - works fine on my XP box, but fails on Server 2003, IIS5.0 I can see WebReference.axd is not being downloaded into Temporary Internet Files from my production box. Trouble...

# re: Whidbey's Client Callback Feature on DotNetJunkies

Has anyone found a solution to the WebResource.axd not being found (404) on Windows 2003? I see two ther complaints about the problem, but no solutions. Any suggestions would be greatly appreciated.

# re: Whidbey's Client Callback Feature on DotNetJunkies

Same trouble here- WebResource.axd not found running on IIS6/Server 2003 (asp.net 2.0 beta 2)- Any help? I'm not even trying to use the 'Client Callback' feature, just the standard javascript postback scripts- I get the 'WebForm_PostBackOptions' is undefined...

# re: Whidbey's Client Callback Feature on DotNetJunkies

Webresource.axd Not found error occurs when we load the system heavily in performance testing.....Could any one help!!

# re: Whidbey's Client Callback Feature on DotNetJunkies

Ditto on the Webresource.axd Not found error. I developed using realeased version VS2003 works fine on my XP dev machine but fails after deployng to Win2003 server. Webresource.axd was Called from the new ASP menu control.

# re: Whidbey's Client Callback Feature on DotNetJunkies

As a workaround you can create an emtpy WebResource.axd file in the root folder.

# re: Whidbey's Client Callback Feature on DotNetJunkies

FIXED!

Don't do those workarounds. Fix it. Now you can, here's the solution. It's an IIS option.

On the aspnet_isapi.dll extension, specifically for the .axd extension, turn OFF option 'Verify that file exist'.

Once WebResource.axd is requested (or any .axd file) IIS will check if the file exists. Since it does not exist, IIS returns a 404.
WebResource.axd is a new built-in HTTP handler in ASP.NET 2.0

# re: Whidbey's Client Callback Feature on DotNetJunkies

I've been getting the 404 error for WebResource.axd as well, but the setting on my site for 'Verify that file exists' is off already...
Any other ideas?

-Joel

# re: Whidbey's Client Callback Feature on DotNetJunkies

It is not Fixed. Your workaround does not work.

I have found Microsoft MVP's say to NOT create a dummy file, do NOT put all your javascripts into one file which you call webresource.axd and upload it yourself. And the reason cited is that ASP.NET 2.0 is SUPPOSED to create the file for you.

But the reality is that it only works on developer stations and not on production IIS 6 servers. Which gives rise to the "it's the code", "no, it's the server" war that takes place between developers and sysadmins.

Nice.

Lots of people with the problem... not a single viable solution. Where's a microsoft knowledgebase article when you need one?

I'm attaching iisstate to see if I get anything out of that.

Here's what I am seeing... when I do anything to the extention... turn on verify file exists, apply the changes, and then turn it off and apply the changes... it works for a while and then breaks again. If I remove the extension and put it back in, it works for a while and breaks again.

SecureIIS has nothing to do with this, because I have turned it off and do one of the above and it works for a while and then it breaks again. By breaks again, I mean it returns webresource.axd as a 404.

This isn't just this product, I am seeing this on custom code too.

If there's a fix or a knowledge base article, or someone knows how to get rid of this in a safe and supported way, please let everyone else know. The only "workaround" we have is to cat together all the js files into one webresource.axd and that takes us to the top of my post.

Thanks for readning,

EDF

# re: Whidbey's Client Callback Feature on DotNetJunkies

FOLLOW-UP:
Items involved: SecureIIS, IIS 6.0, ASP.NET 2.0, webresource.axd

Problem:
On IIS 6.0 with ASP.NET 2.0, your application is giving a 404 file not found error for the webresource.axd file.

iisstate didn't turn up anything useful for me and I wasn't going to chase dumps for days.

My Resolution (if this doesn't work for you, I'm sorry):
This may not be your case, but I found articles that reference wildcard application mappings that make things go crazy if they aren't installed correctly or with the right config.

I had SecureIIS installed on the system, but it was off and I would receive unpredictable results like those above... it would work if you play with the checkboxes for a while and then it wouldn't.

So I made sure to do the following:
In the wildcard application mappings I made sure to put the path into the box and checked do not verify. In my explicit case, I entered "C:\Program Files\eEye Digital Security\SecureIIS\Components\SecureIIS\SecureIIS.dll" and did not check the verify box. I then bounced the system.

This made it work every time and for hours past when it would normally go wierd.

Turning on SecureIIS would lead to the webresource.axd not downloading again. Even though the file would show up now when SecureIIS was off. The SecureIIS log would show it as missing.

eEye Support was no help. I spent hours flipping switches in SecureIIS on and off to no avail.

A Microsoft article explained that webresouce.axd only existed in memory, never on the filesytem and the framework would handle that. But since SecureIIS intercepts both the incoming and the outgoing transmissions and checks against a ruleset, it would intercept the call for the file because webresouce.axd didn't exist on the disk.

SecureIIS was intercepting the request for the file and returning a 404 because the file doesn't exist on the web server, only in memory.

Once I realized this, I found what I needed from the eEye knowledge base article KB000431 (posted here to help those who eEye support couldn't help):

To allow access to all sites that use virtual folders or files, you need to disable the VFE check for all sites via the steps below:

VFE Check - Global Disable:
- Using Explorer, navigate to \eEye Digital Security\Components\SecureIIS\Policies and open up web0.ini with a text editor
- Add (or modify if it exists) the following entry:
[IfFileExist]
Check=0
- Save the INI file.
- Select the “Site Security” component.
- Disarm SecureIIS
- Rearm SecureIIS

Voila!

This allows all the benefits of SecureIIS without checking for if webresource.axd exists. Unfortunately it is a global change and not a selective change. You could do it per site, but all my sites are ASP.NET 2.0, so why bother.

Doing this then, we can get as many of the benefits that we can get away with to keep the site safe and still allow functionality.

I look forward to IIS 7.0 where we finally get the tools and we need and build upon a real good start with IIS 6. THen we won't need these (or as many) extensions. Don't get me wrong... SecureIIS is a good (but expensive) product for what it does, but from what I see in IIS 7, I just don't see that I'll need SecureIIS then.

Thanks for reading. Good Luck!
EDF

# re: Whidbey's Client Callback Feature on DotNetJunkies

Hi,
I am having a website which I am trying to optimize the speed of the site.
The major problem I am getting is the size of webresouce.axd file size and I am getting WebResource.axd,WebResource(1).axd,WebResource(2).axd multiple of them with sizes 21kb, 242kb and 3kb respectively.
Any suggestion on how to reduce the size of these file and to avoid generation of mulitiple of them will be of great help

Thanks,
Dee

# re: Whidbey's Client Callback Feature on DotNetJunkies

Scott Guthrie talks about cross browser support in ASP.NET 2.0, but is the new Client Callback fixed?

# re: Whidbey's Client Callback Feature on DotNetJunkies

I tried a lot of the different options for fixing this which you can find on-line.

The only thing that finally fix this problem for me, was to uncheck the "Verify that file exists" check box for the Wildcard entry I had under IIS Properties for the site>Home directory>Configuration...>"Edit" on the entries for the wildcard entries>Uncheck the check box.

To me it does not make sense that wildcard would overrule the specific entry that states that AXD files should be loaded as such.. (stated in the Application extensions section above) But it seems to do so anyway.

This saved my day that is for sure!

Good luck out there!

EPi_Boy

# re: Whidbey's Client Callback Feature on DotNetJunkies

Webresource.axd Not found error occurs when we load the system heavily in performance testing Could any one help ?

# re: Whidbey's Client Callback Feature on DotNetJunkies

<quote>I've been getting the 404 error for WebResource.axd as well, but the setting on my site for 'Verify that file exists' is off already...
Any other ideas?

-Joel </quote>

i agree with this idea.
my blog is <a href="http://grafikdersleri.co.cc">Photoshop Dersleri</a> Please help

# re: Whidbey's Client Callback Feature on DotNetJunkies

Thanks for your review, my friend. I am happy to read your blog.

# re: Whidbey's Client Callback Feature on DotNetJunkies

useful information content available

# Enker Cam balkon

Camlarin katlanarak ayni noktaya toplanabilme özelligi nedeni ile mevsimsel degisikliklere en iyi cevap verebilen bir sistemdir.

# re: Whidbey's Client Callback Feature on DotNetJunkies

toplanabilme özelligi nedeni ile mevsimsel degisikliklere en iyi cevap verebilen bir sistemdir.

# re: Whidbey's Client Callback Feature on DotNetJunkies

Thanks for posting about this, I would love to read more about this topic.

# re: Whidbey's Client Callback Feature on DotNetJunkies

thank's site

# re: Whidbey's Client Callback Feature on DotNetJunkies

masa ve sandalye portali

# re: Whidbey's Client Callback Feature on DotNetJunkies

sömine modelleri

# re: Whidbey's Client Callback Feature on DotNetJunkies

mobilya dekorasyon rehberi

# re: Whidbey's Client Callback Feature on DotNetJunkies

en yeni oyunlar burada

# re: Whidbey's Client Callback Feature on DotNetJunkies

sandalye modelleri

# re: Whidbey's Client Callback Feature on DotNetJunkies

Set your own life time easier take the <a href="http://lowest-rate-loans.com/topics/home-loans">home loans</a> and everything you want.

# re: Whidbey's Client Callback Feature on DotNetJunkies

I found your website perfect for my needs. It contains wonderful and helpful posts. Carry on this work. In the end, I would like to thank you for making such a nice website.