I have a page with normal Ajax Update panel. There is a submit button which sends the user selection to server. If the user waits for a minute or two, the response from the server is HTTP 413 ( request entity is too large) from server. This only happens when I try to resubmit it after waiting for a minute or two. If a land of the page and submit the form, the server is able to process it.
I have modified the uploadReadAheadSize(as mentioned http://forums.asp.net/t/1574804.aspx) and set it to 200,000,000 - still the problem persists
Http Request
POST https://server/somepage HTTP/1.1
Accept: */*
Accept-Language: en-US,zh-Hans;q=0.9,zh-CN;q=0.8,zh-SG;q=0.7,zh-Hant;q=0.6,zh-HK;q=0.4,zh-MO;q=0.3,zh-TW;q=0.2,zh;q=0.1
Referer: https://server/somepage
x-requested-with: XMLHttpRequest
x-microsoftajax: Delta=true
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Cache-Control: no-cache
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; .NET4.0E)
Host: some-server
Content-Length: 86124
Connection: Keep-Alive
Form-Data...........
The request is over SSL.
I also tried to edit httpruntime configuration in web config
<httpRuntime executionTimeout="3600" maxRequestLength="1902400" />
That solved the error. Correct me, if I am able to correctly describe the problem.
The SSL opens a secure tunnel for some time. So whenever I tried posting data in that time frame everything went fine. But once the tunnel got closed and server preloads the request before client re-negotiation. But preload max length was small and hence it failed.
I tried to set the value of uploadReadAhead value to 120,000 which was greater than the entity request size of about 86,000. Still the request failed (weird .. ????).
It was fine once I set it to the value of approx 10 MB.
Related
I have ASP.NET (4.5) Web Forms application in C#. My application is not hosted in neither in a web farm nor in a cluster.
My application (principal) is responsible to create a SAML message for SSO and send it with a POST method to a service party endpoint (SAMLhandler.aspx) which is another ASP.NET application.
I cannot check the service party endpoint and therefore I have to rely on the error messages they send to me. Every time I attempt to send a SAML message the following error is given:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
In my page the EnableViewStateMac="false" and I set in IIS a fixed machine key, as already seen in other solutions found on the web. I would like to know whether the error is because of something wrong in my application or it is the service provider which has to fine tune something on its side. Anybody has ever had such issue?
UPDATE:
Here you have Request and Response taken from a SAML sniffer (that identifies my SAML message as valid)
POST https://www.serviceprovider.com/SAMLhandler.aspx HTTP/1.1
Host: www.serviceprovider.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1
Referer: https://myApp.com
Cookie: OTDefaultLang=en; Login=LoginURL=http%253A%2F%2Fwww%2Eserviceprovider%2Ecom%2Fdefault%2Easp; brandingid=9; OTLang=en%2Dus; OTSEC670817=VHL8lUncM8RaRm8QbKdzI2Mjzh4-; CteMtRequestId=; AKSB=s=1409581037748&r=https%3A//www.serviceprovider.com/portal.asp; OTSESSIONAABQRN=FA7C6FA5G873EG4D89G82E2GE8809C8075EF
Content-Type: application/x-www-form-urlencoded
Content-Length: 5989
Service Provider Response:
HTTP/?.? 302 Moved Temporarily
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /Errors/500.100.asp?aspxerrorpath=/SAMLhandler.aspx
Server: Microsoft-IIS/7.5
webserver: usseat_cte95
Content-Length: 187
Date: Tue, 02 Sep 2014 14:14:16 GMT
Connection: keep-alive
Set-Cookie: ADRUM_BT=R%3a40%7cclientRequestGUID%3a6c526398-acce-4ae7-ae29-ee40e42648ab%7cbtId%3a553%7cbtERT%3a10; expires=Tue, 02-Sep-2014 14:14:46 GMT; path=/
If my browser uses cache (local cache), does it GUARANTEE that each HTTP request it sends contains "IF MODIFIED SINCE" header line?
If not, how do I define that it will ? and what if I define a proxy server to the browser ? will it add it automatically then?
thanks in advance
I was just working on this with my RESTful web service and ran a few tests for a particular resource. First of all I was trying to control the browser cache from my web server by setting the following HTTP headers on the HTTP response for the resource:
Cache-Control: must-revalidate, max-age=30
Last-Modified: Mon May 19 11:21:05 GMT 2014
Expires: Mon May 19 11:51:05 GMT 2014
Then from my web UI I have a timer that periodically (every 5 seconds) does a GET on the resource that I've said is cacheable. Since the resource in the browser cache has not yet expired the GET request for the resource is served from the browser cache, however, once the "max-age" has expired the next GET request goes to the server and the browser adds the "If-Modified-Since" header with the "Last-Modified" date as the value like this:
[GET] - /cms_cm_web/api/notification
referer: http://localhost:8080/cms_ui/#/
accept: application/json, text/plain, */*
accept-language: en-us
ua-cpu: AMD64
accept-encoding: gzip, deflate
user-agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
host: localhost:8080
if-modified-since: Mon, May 19 11:21:05 GMT 2014
connection: Keep-Alive
This came from IE9 browser. I get the same from latest Firefox and Chrome browsers as well.
From here the server can look for the "If-Modified-Since" header and if it determines the resource has not been modified then it returns a 304 Not Modified response, otherwise, it returns the resource representation with a 200 OK response.
so according to the HTTP specification you can control caching using "Expires" and/or "Cache-Control" headers together with a "Last-Modified" header. This will cause the browser cache to perform what's called a "conditional GET" request as it includes the "If-Modified-Since" header.
Here is the scenario:
A client has a fairly standard IIS site published via a UAG portal trunk. Clicking the link on the portal page from an external client is supposed to effect a redirect to said IIS site, hosted internally. Simple enough.
For every single domain user except one, this works just fine. Here is the output from a successful redirect:
GET
/uniquesig6192b908e3f362bf06404502c58f28f18ec5923ef22832661845904b888b6fc7/uniquesig1/[sitename]/[appdirectory]/[resource].aspx
HTTP/1.1 Accept: text/html, application/xhtml+xml, / Referer:
https://portal.[company].com/[appdirectory]/Pages/[resource].aspx
Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 10.0;
Windows NT 6.1; Trident/6.0) Accept-Encoding: gzip, deflate Host:
[othersubdomain].[company].com
DNT: 1
Connection: Keep-Alive
Cookie: ASP.NET_SessionId= r5uavyvx0drz42453cml4055;
__utma=128077646.1396813579.1381846816.1381846816.1381846816.1;
However, there is a single AD user that does not successfully redirect, regardless of browser, OS, location, ISP, you name it. We had them recreate the user in AD to create a different descriptor and verify that user object wasn't corrupt somehow. When the 'bad' user attempts to click the redirect link, the following GET request is generated:
GET
/uniquesig6192b908e3f362bf06404502c58f28f18ec5923ef22832661845904b888b6fc7/uniquesig1/[sitename]/[appdirectory]/[resource].aspx
HTTP/1.1 Accept: text/html, application/xhtml+xml, / Referer:
https://portal.[company].com/[appdirectory]/Pages/[resource].aspx
Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 10.0;
Windows NT 6.1; Trident/6.0) Accept-Encoding: gzip, deflate Host:
[othersubdomain].[company].com
DNT: 1
Connection: Keep-Alive
Cookie: __utma=128077646.1396813579.1381846816.1381846816.1381846816.1;
As you can see, the ASPNet session ID cookie is never sent to authenticate with IIS. at first, I thought it might be an affinity problem, wherein a cookie is not recognized due to load balancing; however, we drain-stopped one server to ensure that traffic was only authenticating on one box. ASP.NET cookies are issued by IIS, which again, would indicate a potential issue with IIS. However, again, it is confined to a single user. Another possibility is that the user has Logon Permitted hours incorrectly set, which might deny them that session ID cookie from IIS. According to the client, no dice.
Can anyone see anything I might be missing? Thanks!
I am building an ASP.NET web application use ajax to request some content and it works well in FireFox, Chrome but in IE not stable:
When use login he/she can view owner files, if not login page return string "no permission".
I logined website, I refresh page in IE sometime it show file and sometime it show "no permission" (that not login) I refresh again it show file. I mean that some request it works correct and some request it works wrong! I have seen HTTP request and see that all cookie sent correct.
Here one request
POST http://abc.com/xxx.asmx/GetFileInfo HTTP/1.1
x-requested-with: XMLHttpRequest Accept-Language: en-us
Referer: http://abc.com/?work=home Accept: application/json,
text/javascript, /; q=0.01 Content-Type: application/json;
charset=utf-8 Accept-Encoding: gzip, deflate User-Agent:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0; .NET4.0C; .NET4.0E) Host: abc.com
Content-Length: 27 Connection: Keep-Alive Pragma: no-cache
Cookie:
__utma=63255935.688817123.1357236998.1357236998.1357390216.2; __utmb=63255935.5.10.1357390216; __utmz=63255935.1357236998.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); .ASPXAUTH=E83DCA879A8A9AF5DAE72854241CFEBF2AF4BCE7E2227465E71FB428D6816C555176F9F1A1E94CB34F9C48C4FC7C64FBCAA013672182720254821F802242B90098A01A727AA30D4A621B921536B0F5E36F9DE9382972CE7AFC52EA819669E8B8F7D4C5ECCA1EDE07D971CEA64E5847BBC0E9ACB7B26F07BC769422B8C68A5F04F2B183533C95CC6849A8B98D83F22BC306FF564FE8519A1738AC8DB1F4C55A5B6E84FC02D863C22AF3CBD04E70186C497A240313C107DD74B3D28F2AE6BF95FED3E6EA2CC7EE1767F9E9FCBD5A6EEF77EF61198BD65342E6C10B978595DADA17FBDC83A2;
ASP.NET_SessionId=ibxe0t55thibhb45vcgkxmvx; __utmc=63255935
{'ID1':'13','ID2':'2'}
How I fix it?
Thank you!
I know why, because I not set Machine Key in web.config file.
I am developing with the .NET framework, using jQuery 1.4.2 client side.
When developing in Firefox version 3.6, every so often an one of the many ajax calls I make on the page will fire twice, the second will return successfully but will not trigger the success handler of the ajax call and the first never returns anything. So basically the data is all sent to the server and response is sent down but nothing happens with the response.
Here is an example of the call I am making. It happens to any of the ajax calls, so there is not one particular that is causing the problem:
$.ajax({
type:"POST",
contentType : "application/json; charset=utf-8",
data:"{}",
dataType:"json",
success:function(){
alert('success');
},
error:function(){
alert('error');
},
url:'/services.aspx/somemethod'
});
})
From firebug, here are the headers of the first call which in firebug shows as never completely responding, meaning i see no response code and the loader gif in the firebug never goes away.
Note:In firebug it usually says Response Header but for the first call this space is blank
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept application/json, text/javascript, */*
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
X-Requested-With XMLHttpRequest
Referer http://mydomain.com/mypage.aspx
Here is the header from the second request which just appear to complete in firebug (i.e response is 200):
Response Header
Server ASP.NET Development Server/9.0.0.0
X-AspNet-Version 2.0.50727
Content-Type application/json; charset=utf-8
Connection Close
Request Headers
Host mydomain.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3)
Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/json; charset=utf-8
Referer http://mydomain.com/mypage.aspx
To summarize my question, why are two requests being made and why are neither of them triggering a success or error handler in the ajax call.
I have seen this article about firefox 3.5+ and preflighted requests
https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests
In the article is says if a "POST" is made with any other content type than
"application/x-www-form-urlencoded, multipart/form-data, or text/plain" than the request is pre-flighted. If this is the case, this should happen to all of my calls.
Thanks
This isn't an answer as much as a proposed temporary workaround. Make the call synchronous with async:false and see if things work again.
I've been tearing my hair out over a similar-sounding bug recently.