Ok, thanks. Would it be possible to test a beta version as soon as this JSON change is built in? I could test then if this change works as expected in that environment.

Eric

Hi Gordon,

Thanks for your reply. From your answer I understand that that data being sent back from the server will be in JSON format instead of XML.

Please notice that the problem mentioned in this thread is not the server data. The problem is the data that the client (the web browser) sends to the server. That currently is neither XML nor any other standard format. It is some Intersoft proprietary format, as you can see in one of my posts above. I need to know if this will change. Or did you want to say that the data format sent by the client will also change to JSON format?

You also didn't mention when the 2011 R1 will be released. If this is not certain, can you give an estimation?

Thanks,

Eric

Hi Handy,

The problem is this: The dropdown is a filter setting for the grid. What selection the user made is also shown in the grid column titles (header). No database call is necessary for that - it's just shown there. The grid data itself comes from the database and depends on the dropdown selection. You cannot predict what data will be returned from the database just by looking at what selection the dropdown is. You are doing this in your sample.

When there is no single row returned from the database, then I create an artificial row, containing the text "no data available" in the first field and expand the field size to the whole screen width.

In your sample you are just checking if the dropdown is on position ND and in that case you set the width of the first column to full-screen width or normal. But you cannot know if the database will return any data just by checking the position of the dropdown. You have to make a database call. And this means you are actually using two calls - one for the width setting here and the second one to actually fill in the data.

I hope you can see the problem now.

Attached is your sample slightly modified. Now the database returns no rows every 30 seconds (see code). Also I included a two-seconds delay into the "database call". This way you can see that two calls are necessary and how slow it is. Also the initial view doesn't reflect the empty-status (the width is wrong). If you look at this sample, you can see the following:

• On initial startup, the dropdown is on DDLa and both grids are empty. -> ok
• On initial startup, both grids say "no data" -> ok
• On initial startup, column Description uses full width -> wrong
• Changing dropdown sets both grids to invisible -> ok
• Clicking Refresh button refreshes both grids -> ok
• Refreshing time should be 2 x cDelay (once for each grid) -> wrong, takes longer, because two calls are being made
• Column headers show dropdown selection -> ok
• Selecting a row in the upper grid updates the lower grid -> ok
• After refreshing, sometimes no data will be returned and special row with text "no data" shows up -> ok
• After refreshing, sometimes no data will be returned and special row with text "no data" shows up and uses full width -> wrong
• After refreshing, sometimes no data will be returned and special row with text "no data" shows up in Description column and all other columns are hidden -> wrong
• etc.
  

Regards,

Eric

Hi Handy,

Maybe you didn't understand the problem we are facing.

Your control is sending this data to the webserver:

WebGridRequest=
¢WebGrid>¢request id="ctl00_ContentPlaceHolder1_grdMain" action="Custom"/>¢/WebGrid>

(¢=0x03 character)

And between the client and the server there is a security filter that checks for this pattern in any field:

" abc = … >

As you can see this does match. This means that the entire POST request will be filtered away and not even reach the IIS.

This filtering is not done for fun. This is because typical XSS-exploiting attacks are using exactly this pattern.

The product that filters this away is AdNovum NevisProxy Version 3.9. Please see here:

http://www.adnovum.com/en/products/index.php?page=secprod&subpage=nevis&subsubpage=nevisproxy

In other words, your WebGrid is not compatible with using such security software. I imagine that any other security software with input validation would also filter these requests away, so it's not specifically this product.

In any case I would suggest that you make your WebGrid compatible with such filtering software.

Client Binding is not possible and even if using the WebFlyPostBackManager would work, this would mean to reengineer the entire application. We use WebGrid on every page and I don't want to change all this handling. For me this just means we cannot deploy the existing application with WebGrids to such an environment.

Regards,

Eric

Hi Handy,

In the meantime I could get a HTTP protocol analyzer installed. After loading the page for the first time, I can see a few requests like this:

POST /blabla.aspx HTTP/1.1
Accept: */*
[more header fields]

WebGridRequest=¢WebGrid>¢request id="ctl00_ContentPlaceHolder1_grdMain" action="Custom"/>¢/WebGrid>
&__VIEWSTATE=/wEP...

(The character ¢ stands for ASCII code 03.)

As you can see, there is request data from WebGrid. And this data contains the 'greater as' sign, but not used as correct XML. Such data looks exactly like input from a hacker trying to XSS-exploit a normal web form.

This means that requests like these get filtered away by security software that do input validation.

This means in other words that WebGrid is not compatible with such environments. Can you confirm that this is by design?

Regards,

Eric