I am running into a randomly occuring issue, and it looks like either there is a bug in the third party control we are using or the size of a form field is limited. I've seen there is a limit in classic asp http://support.microsoft.com/default.aspx?scid=kb;EN;q273482 but is there a limit in .net?
I believe if we reached the max limit setting on the entire post body that asp.net would generate an error instead of truncating the form field. I know most likely this an error in the third party control but I want to vette all other possible options. Essentially what is occuring is they are posting a url encoded xml msg in the body and the xml is getting truncated sometimes.
Thanks in advance.
check to see that there isn't a limit in the database table or stored procedure. if there isn't a limit there then maybe the parameter variable is declared with a limit in the .net code. the default maxRequestLength set in the machine.config is 4096 which should accommodate any posting in a form
there shouldn't be any limits because i have projects where people post upwards of 200,000 characters to a single form field.
Related
I want to use viewstate variable's value which is saved in one page on another page. But while doing so it shows NullReferenceException. I am new to ASP.net. Please Help me out.
in register.aspx
ViewState("name")=textbox1.text
in success.aspx
dim a as string
a=ViewState("name").toString
Use Session["name"] = textbox1.text...
If I am not mistaken, you don't have direct control or should have direct control over viewstate.
ViewState is the technique to persist state across postbacks and is lost when you load another page. therefore you will need to use another way to send the data to the next page. Read up more here on MSDN
The common choices for sending data across pages include:
QueryString
By setting up the previous page property
Session variables
ViewState is restricted to a page, so it cannot be used on another page. The reason is that ViewState is serialized in the page output in a hidden field that is transferred to the client and back to the server upon a postback.
If you want to transfer data to another pages you have several other alternatives:
As #AnastacioGianareas also pointed out, Session memory is one of them. It is located on the server, but sessions will expire after a certain time of user inactivity. Being located on the server, it reduces application scalability if you have many users and lots of memory allocated in the session.
Hand over the data as a query string parameter to the other page, e.g. redirecting to "Success.aspx?name=". This will work for smaller amounts of data that you can put into the query string (e.g. ids or names). It is important that a client can also request Success.aspx with that query string parameter, so it should be reserved for uncritical data and be validated carefully.
Use a cookie to transfer it to the client and back again.
This link gives a good overview of the alternatives.
From MSDN:
View state is the method that the ASP.NET page framework uses by
default to preserve page and control values between round trips. When
the HTML for the page is rendered, the current state of the page and
values that need to be retained during postback are serialized into
base64-encoded strings and output in the view state hidden field or
fields.
Options to persist data between pages are varied and depend upon your requirements, this page on MSDN describes each of these options and the considerations you should make.
For your requirement either QueryStrings, SessionState seem like the best solution.
As a side note, always validate your 'State' variables (regardless of which method you chose) to ensure that they aren't null and are of the expected type. i.e. all these values will be stored as Strings, if you are going to use a variable as another type (an int, double etc) you should make sure this is valid. Also, should you go down the querystring route, take into account any security considerations as users may / will modify these values.
Again I come to you guys for your expertise and advice on an issue that I am having. I was wondering if any of you would know how to detect if a web page has been modified using VB.NET. I need to be able to set up a task which periodically (like once a week) scans the user inputted web pages and if the web page content has changed, I need to fire off an email to an individual that it has changed (not the exact location on the page itself). I'll be storing the HTTP status and of course the page data itself as well as the date of when it was last modified. Of course this needs to be very fault tolerant since it could be another week before the check runs again. Any help would be great. Thank you.
EDIT
New twist on this question sorry. I had more time to think about what we wanted. So... Detecting ANY change on a web page would be kind of silly since time dependent elements of the page would change every so often. Instead, what I would like to do is be able to detect the documents in the page. For instance if there are excel, word docs, or pdfs that get changed on that page. So, I'd run the hash on these documents then on some sort of schedule do a check to see if new documents have been added or if the old documents have been modified. Any suggestions on how to detect the documents embedded on the page and running the hash? Thanks again!
As I mentioned in a comment, this sort of job is what checksums (also known as hash functions) were designed for.
You code for will look something like this:
- for each webpage of interest
- pull webbpage
- calculate checksum of contents
- is current checksum different to last checksum?
- if yes, send email
- store new checksum and other appropriate data
The .Net framework has a number of checksums available. The two most popular are MD5 and sha1
In addition to the checksum option, there are also various Diff function that achieve this, and provide much more information than changed=true/false. This question has more info:
How to tell when a web page has changed by x% in VB.net?
In pages that have a viewstate that spans 10-15KB what would be an optimal value for
<pages maxPageStateFieldLength="">
in the web.config in order to reduce the risk of potential truncation leading to viewstate validation errors?
The maxPageStateFieldLength doesn't limit the size of the view state, so it won't be truncated.
What it does is simply control how much of the view state will be placed in one hidden field. If the view state is larger than the maxPageStateFieldLength value the view state will simply be split into several hidden fields.
The default value is -1, meaning that the view state is put in a single hidden field, which is normally the most optimal.
I am currently running into a problem where we are getting "HttpException Due to Invalid Viewstate" errors for only Firefox users. I am also seeing "System.Web.HttpException: An error occurred while communicating with the remote host. The error code is 0x80070001" exceptions paired up with the viewstate ones.
I believe that firefox has possibly got a max size on (possibly) hidden form fields - i need to verify this. I'm now looking to chunk up the viewstate using maxPageStateFieldLength to hopefully resolve (in the short term). The longer term solution is to refactor the aspx page to do a paging query for grid (instead of pulling down all the rows in one go - which is not a good thing to do).
IMHO, you should put in a maximum that is fairly large but not unlimited. I'd say 1MB is a start.
I have an application that holds data referencing 300,000 customers. When a user did a search the result was often bigger than our MaxRequestlength would allow, we have dealt with this in two ways: We have increased our MaxRequestLength to 102400 (KB) and required the user to supply two letters of the first Name and two letters of the last name, to limit the sheer # of customer records returned. This keeps us from exceeding the MaxRequestLength limit.
I was just wondering if anyone had any insight in to whether this was a particularly good approach, whether there is a limit to how big MaxRequestLength could be or should be, and what other options might be useful in this situation.
Most web applications I have seen deal with this by returning a paginated list, and displaying only the first page of results.
In modern implementations using ORM's, "Skip" and "Take" operators are used to retrieve only those records which are required for a given page.
So any given request is no longer than the number of records on one page.
I would recommend paging the results instead of displaying everything. I would also suggest adding multiple search fields allowing your users to filter their results even further. This will allow your user to find what they are looking for faster.
As you can guess from my comment, I think MaxRequestLength only restricts the size of the request (-> the amount of data sent from the client/browser to the server).
If you are exceeding this limit, then this probably means that you have a huge ViewState which is sent with every response. ViewState is stored in a hidden field on the page and is sent back to the server with every PostBack (and that's where the MaxRequestLength setting could come into play). You can easily check this by looking at the source of your page in the web browser and looking for a hidden INPUT element with the name "__VIEWSTATE" and a large string-value.
If this is the case, the you should try to reduce the size of the ViewState, e.g. by
setting ViewState="false" on your controls (GridView or whatever) and re-binding the control on every PostBack (this is the recommended approach)
storing the ViewState on the server side
compressing the ViewState
If your requirements allow it, I would suggest implementing server-side paging. That way you only send one page worth of records over the wire rather than the entire record set.
300,000 records is a completely unusable result set from a human perspective.
As others have said, page the results to something like the top 50 or 100 records. Let them sort it and provide a way to narrow the search criteria.
For perspective, look at google. They default to 10 records per page. Part of the reason for this is that people would rather provide more criteria than go spelunking through a large result set.
What does VaryByParam do on an asp.net directive? I have tried looking on the web, but can't actually understand what it does.
Thanks
Please see OutputCacheParameters.VaryByParam:
Gets a comma-delimited list of query
string or form POST parameters that
the output cache uses to vary the
cache entry.
Basically what this means is that the output caching of a given page will use certain values to determine which cache should be returned since a dynamic page may have different redered representations of itself.
Those different representations tend to be driven by user-provided data and this property allows you to configure which values from the query string or a POST payload will control that.