I have an application under Yii, and I have this problem regarding my urls.
With the Yii CGridView, when we filter, the application passes an ajax GET request to the server in a form of a very long url. example:
http://site.com/reports/default/index/MEmailrequestsList%5Bid%5D//MEmailrequestsList%5Bname%5D//MEmailrequestsList%5Bperson%5D//MEmailrequestsList%5Bemail%5D//MEmailrequestsList%5Bcreated%5D//MEmailrequestsList%5Busersender%5D/josalie/MEmailrequestsList%5Bstatus%5D//MEmailrequestsList_page/2/ajax/reportsgrid?ajax=reportsgrid
With Firefox or Chrome's firebug, it doenst show any errors, just a failed status. Upon reviewing, it gives off a status of connection reset.
I am running the application in Windows, under WAMP.
With other urls (non yii) (
http://site.com/samplepage/?id=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1&poads=2&asd=1...
)
I think I did it.
I managed to fix the issue by making the URL of the paginations to use the default get parameter url symbols (? and &). I did this by placing a 'appendParams'=>FALSE to the UrlManager of the application.
It is fixed now and hopefully somebody will find this helpful.
Related
I'm running Firefox 36.0.4 on Windows 7 32-bit. I've diabled all add-ons, extensions and user scripts before retesting this.
I'd like to step through JavaScript code that is served up in a <script> tag in the HTML document being produced by a Java (Tomcat) web server.
Unfortunately, when I select the HTML document under Debugger > Sources, the source of the page returns to the login page of the application - it appears that session information is not being used to request the source.
I stepped through the server-side code and found that the correct session cookie values were being sent for the real page request and some AJAX requests sent by the page. However, when I tried to load the page source in the JavaScript debugger, I found that an incorrect session cookie was being sent by the JavaScript debugger.
I can replicate this behaviour in other webapps, not just my own. For example, Stack Overflow:
Is this a configuration issue, or a bug in the Firefox Developer Tools?
I can't reproduce your problem using StackOverflow as an example, at least in Firefox Developer Edition ( currently version 38 ):
One thing that might help - try disabling the cache while the toolbox is open - this setting is in the developer tools setting panel ( click on the 'gear' icon at the top right of the toolbox ):
After reviewing canuckistani's answer, I downloaded Firefox Developer Edition. Seemingly, the problem was fixed.
Five minutes in, I became sick of being asked whether to remember passwords and having to manually clear session cookies (I prefer being able to do it by simply closing the browser) - it makes testing easier.
As per usual, I went to Options > Privacy > History to disable this behaviour, by setting the value to Never remember history.
Changing this setting requires the browser to restart. However, upon restarting, I once again saw the same erroneous behaviour - the wrong session cookie was being sent to the web application again.
The workaround here is to not use the Never remember history setting. I have filed a bug report at Mozilla.org Bugzilla.
I have an MVC app and when I first open it up (in a new browser, ie new session) I am getting some strange characters added to my url after the site name part. It always starts with (X(1)S( and the characters change each time.
(X(1)S(y2bk1ahqgpv42uwh0mcpsdxw))
Does anyone have any ideas what is causing this? Is this some cookie setting in IIS or web.config?
It's causing some problems, one of which is the modelstate is invalid due to an error with no error messages.
Deploying to IIS.
Get the following response in Fiddler:
HTTP/1.1 302 Found
Location: /mysite/(X(1)S(hvuk0jbaokfmxtlvm54d4cvc))/
<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="/mysite/(X(1)S(hvuk0jbaokfmxtlvm54d4cvc))
Not sure what other info I can give that could be relevant, I'm hoping someone has seen these characters before and know what they're about.
Thanks
So this was bothering me all day then as soon as I put it on SO I find the reason.
The original URL I was requesting had the following querystring parameter.
&AspxAutoDetectCookieSupport=1
Remove this and although it gets appended automatically the other characters don't and everything works.
The problem was we had copied the URL in the past with this parameter as it had been automatically added. However if you request a url with this parameter in it, you get the above issue.
I think this is the solution, maybe others know some more information.
I have successfully implemented MVC bundling for my MVC application. There is one problem with the run time which runs under HTTPS.
I am sure there is a problem because when I switch the debug field to false the user gets the warning message "This page contains secure and nonsecure items. Do you wish to proceed?
I know that I can turn this prompt off using the security setting in IE. I would like to know if there is something I can do to the application so that bundled scripts and styles come through the secure pipe.
If you use the Scripts.Render helper to include the bundle it will use the same HTTP scheme as the one used to request the main page. So if the main request was done over HTTPS then this helper will generate a <script> element using HTTPS. You could use the Net tab of FireBug to see which resources are served through HTTP and HTTPS and be able to isolate the problem.
Thank you for this suggestion. I figured out that the problem was coming from modernizr-1.7.js
The strange thing was that this problem only occurs when modernizr is bundled. I removed modernizr because we don't really need it.
Two clients complains on HTTP Error 400 from Mozilla Firefox 3.6.9. This happens when they open any link - both mvc application and also any static images, which are hosted on Classic application pool without any code.
Exact error message is HTTP Error 400. The request is badly formed
No errors in windows log and application error log. Proxy in browser is set to off.
Other browsers works fine for them.
Any ideas about what could cause such behavior?
For now, i can see only one option - ask them to install Firebug, but this is not really user friendly.
For some reason, cookies was corrupted and this was leading to HTTP 400 error.
After user cleaned cookies for this website he was able to get page.
I still need to investigate what exactly went wrong and find source of this problem but it is clear that I need to review all places where I do cookie creation.
I am using
Response.Redirect("someurl",true);
in the page_preInit event to redirect all the requests that come to a page. It works fine on Firexox, but if i access the page from internet explorer 7/8, it says page can not be found and will not redirect to new URL.
Any idea why this happens??
Update:
I tried giving a radom URL in the redirect such as google.com and it works fine. Actually the URL I am trying to redirect is not accessible on my machine, it is on another VPN. I guess IE will not change the URL on the addressbar if it can not access the URL. Firefox on the other hand changes the address on the address bar.
Is your Response.Redirect contained within a try/catch block? This can cause issues with Redirection.
As i mentioned on the Update, IE wont change the URL if it returns 404. Since i had no access to the URL i am redirecting, it was returning a 404. But firefox behaves differently.
I also had a similar issue where Internet Explorer would not redirect using a standard Response.Redirect call. I also saw the same issue on certain Android devices on WIFI, but who worked correctly on cell service. Very strange.
The problem is with Microsoft's legacy redirect method in .NET. Certain network routers and older browsers handle the response codes differently. Here's the change to C# code that fixed it:
OLD CODE:
HttpContext.Current.Response.Redirect("www.mysite.com", true);
NEW CODE:
WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.Redirect;
WebOperationContext.Current.OutgoingResponse.Headers.Add("Location", "www.mysite.com");