You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne W <wa...@gmail.com> on 2011/08/12 06:29:20 UTC
Re: Ajax response render as source in the browser
just to say we still have this issue and its getting more and more
worse as people are moving to FF and Chrome.
We have no idea how to solve as we cannot reproduce it consistently.
On Mon, Dec 13, 2010 at 8:41 PM, Wayne W <wa...@gmail.com> wrote:
> Hello everyone,
>
> I thought you might be interested. At the weekend I experienced this
> problem myself on my local machine, so I had the chance to debug and
> figure what was happening.
>
> The short version is 99.9% sure its a javascript engine bug on Firefox
> (and we've had a couple of users say they had it on Chome). The only
> way to 'fix' the issue was to clear all cached data from the browser.
> Restarting the browser or the server made no difference. I will report
> this to Mozilla today.
>
> Luckily I could consistently make it fail and succeed so I could debug
> and trace exactly what was happening. I don't know if thus is
> something to do with the URL format of the request (I very much doubt
> it) but its odd that this has never been reported before, but clearly
> it wasn't working for use and for some of our users.
>
> We observed the following:
>
> GOOD REQUEST
>
> We could set break points in the wicket-ajax.js and step though it
> until the Request.doGet line 841 where transport.send(null) is called.
> The headers where:
>
> Response Headers
> Content-Type text/xml; charset=utf-8
> Pragma no-cache
> Cache-Control no-cache, must-revalidate
> Expires Mon, 26 Jul 1997 05:00:00 GMT
> Content-Length 3346
> Server Jetty(6.1.4)
>
> Request Headers
> Host foo7.glasscubesdev.com:8080
> User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
> rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
> .NET4.0C)
> Accept text/xml
> Accept-Language en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
> Accept-Encoding gzip,deflate
> Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive 115
> Connection keep-alive
> Wicket-Ajax true
> Wicket-FocusedElementId changeBillingAddress177
> Referer http://foo7.glasscubesdev.com:8080/?wicket:interface=:20::::
> Cookie JSESSIONID=1vsuz0qz6v33o
>
>
>
> Now for the BAD REQUEST
>
> At first none of the break points in the javascript would hit at all ,
> we'd click on the ajaxlink and immediately we would see the ajax
> response from the server in the browser window and the URL in the
> address bar as:
> http://foo7.glasscubesdev.com:8080/?wicket:interface=:44:changeBillingAddress::IBehaviorListener:0:&random=0.7035102055608244
>
> So we knew the javascript must of been running as the random parameter
> was different each time it failed.
> I then realised that I needed to 're-set' the break points in the
> wicket-ajax.js again. It seems that firefug was treating the js file
> as a different file when on the failing request versus the good
> request. Anyhow once I realised that I could step through it again to
> the same line in the Request::doGet(). At this point we got the
> behaviour as described before with the URL in the browser and the ajax
> response in the page. Looking at the headers we can see:
>
> Response Headers
> Content-Type text/xml; charset=utf-8
> Expires Mon, 26 Jul 1997 05:00:00 GMT
> Cache-Control no-cache, must-revalidate
> Pragma no-cache
> Content-Length 3346
> Server Jetty(6.1.4)
>
> Request Headers
> Host foo7.glasscubesdev.com:8080
> User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
> rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
> .NET4.0C)
> Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
> Accept-Encoding gzip,deflate
> Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive 115
> Connection keep-alive
> Cookie JSESSIONID=1vsuz0qz6v33o
>
>
> The wicket specific headers and content type are not there, even
> though the code was explicitly setting them just before the call to
> transport send.
> Our only conclusion is that is must be a javascript engine bug, we
> just surprised this has never reported before as its not a wicket bug
> .
>
>
>
> On Tue, Nov 16, 2010 at 5:29 PM, Wayne W <wa...@gmail.com> wrote:
>> Hello,
>>
>> we've upgraded the apache to 2.2.15 in production and this made no difference.
>> However today we got a screen shot from one client who has been having
>> the issue see:
>>
>> https://home.glasscubes.com/share/code/8a8c7ecf37fe9d95cefaf787529b0828
>> (you'll need to download to see the details of the URL)
>>
>> What's really odd about this is that it looks like the browser is
>> doing a HTTP GET rather than using the xml request object - you can
>> plainly see in the browser the URL. Looking at the code for the
>> onclick event it looks (to me normal) (see below).
>>
>> Anyone got any further ideas on this? Its like the wicketAjaxGet is
>> literally doing a GET!
>>
>>
>> <a onclick="if (document.getElementById('spinnerContainere'))
>> (document.getElementById('spinnerContainere')).style.display =
>> 'inline';if (document.getElementById('filterEverythingc'))
>> (document.getElementById('filterEverythingc')).disabled = true;var
>> wcall=wicketAjaxGet('../?wicket:interface=:1:mainPanel:filterContainer:filterEverything::IBehaviorListener:0:1',function()
>> { if (document.getElementById('spinnerContainere')) {
>> (document.getElementById('spinnerContainere')).style.display =
>> 'none';}if (document.getElementById('filterEverythingc'))
>> (document.getElementById('filterEverythingc')).disabled =
>> false;}.bind(this),function() { alert('There was a communication
>> problem. Please try refreshing your browser');if
>> (document.getElementById('spinnerContainere')) {
>> (document.getElementById('spinnerContainere')).style.display =
>> 'none';}if (document.getElementById('filterEverythingc'))
>> (document.getElementById('filterEverythingc')).disabled =
>> false;}.bind(this), function() {return Wicket.$('filterEverythingc')
>> != null;}.bind(this));return !wcall;" id="filterEverythingc"
>> href="#">Everything</a>
>>
>>
>>
>> On Fri, Nov 12, 2010 at 4:31 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>>> We're running 2.2.15 with the AJP connector. Before we'd pinpointed
>>> our problem, we were considering using the HTTP connector instead.
>>> That affects the requestor's IP in Tomcat though, so I'm glad we
>>> didn't have to.
>>>
>>> On Fri, Nov 12, 2010 at 12:31 AM, Wayne W <wa...@gmail.com> wrote:
>>>> Thanks Dan,
>>>>
>>>> I thought I'd foudn my answer then! However we're using:
>>>> Server version: Apache/2.2.9 (Unix)
>>>> Server built: Dec 10 2008 18:22:18
>>>>
>>>>
>>>> So it looks like we already have that fix.
>>>>
>>>> Which version are you running?
>>>>
>>>>
>>>>
>>>> On Fri, Nov 12, 2010 at 5:19 AM, Dan Retzlaff <dr...@gmail.com> wrote:
>>>>> We had this issue with Apache HTTPD in front of Tomcat. "Random" pages
>>>>> would be rendered as text/plain instead of text/html.
>>>>>
>>>>> Bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=43478
>>>>> Discussion: http://markmail.org/message/btwcnbl2i7ftwj4n#query:mod_proxy_ajp%20plain+page:1+mid:btwcnbl2i7ftwj4n+state:results
>>>>>
>>>>> Patch against Apache 2.3.0:
>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?view=markup&pathrev=579707
>>>>> Backport into Apache 2.2.7: http://archive.apache.org/dist/httpd/CHANGES_2.2.8
>>>>>
>>>>> Upgrading Apache solved the problem for us. So, what version of Apache
>>>>> HTTPD are you using?
>>>>>
>>>>> Dan
>>>>>
>>>>> On Mon, Nov 8, 2010 at 8:30 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>> well, you do have apache infront of tomcats, which *is* a proxy. i
>>>>>> would write a jmeter script that tried to reproduce this and when you
>>>>>> can run it against tomcat (not going through apache) and see if you
>>>>>> can repro it that way. im guessing its something in your apache config
>>>>>> since you are the only one having this issue.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Sun, Nov 7, 2010 at 11:59 PM, Wayne W <wa...@gmail.com> wrote:
>>>>>>>> the browser. do you have a proxy between the servlet container and the
>>>>>>>> outside? maybe something is injecting a redirect or something weird.
>>>>>>>
>>>>>>> I did wonder if there was weird redirect issue, but after doing a lot
>>>>>>> of reading yesterday it seems the xmlrequest object *should* handle
>>>>>>> redirects fine. However either way we're not doing anything like that.
>>>>>>> We've got a couple of tomcat instances load balanced through apache,
>>>>>>> routed via a hardware firewall and out of the datacenter, so no
>>>>>>> proxies or anything at least I'm aware of.
>>>>>>>
>>>>>>> Its very frustrating.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>>> the only way i can see that happenning if the url is no longer
>>>>>>>> processed by wicket's ajax support and so the response just ends up in
>>>>>>>> the browser. do you have a proxy between the servlet container and the
>>>>>>>> outside? maybe something is injecting a redirect or something weird.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Sun, Nov 7, 2010 at 8:26 AM, Wayne W <wa...@gmail.com> wrote:
>>>>>>>>> thanks Igor,
>>>>>>>>>
>>>>>>>>> I've just spent a few hours stepping though the code and I cannot see
>>>>>>>>> anyway the content type could be set wrong - I see the content type is
>>>>>>>>> set in the final respond(requestCycle) method, so I'm now thinking
>>>>>>>>> this is not a content type issue.
>>>>>>>>>
>>>>>>>>> However we just got another user email with a screen shot showing the
>>>>>>>>> wicket ajax-response in the browser so something is up.
>>>>>>>>>
>>>>>>>>> My javascript knowledge is weak at best so I've not been able to tell
>>>>>>>>> much from the js .
>>>>>>>>>
>>>>>>>>> Any ideas on how we can resolve this or at least get more info?
>>>>>>>>> many thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>>>>> see AjaxRequestTarget class, this is where the response is generated
>>>>>>>>>> on the serverside
>>>>>>>>>>
>>>>>>>>>> wicket-ajax.js is where it is processed on the client side.
>>>>>>>>>>
>>>>>>>>>> -igor
>>>>>>>>>>
>>>>>>>>>> On Sat, Nov 6, 2010 at 2:49 AM, Wayne W <wa...@gmail.com> wrote:
>>>>>>>>>>> Hi Igor,
>>>>>>>>>>>
>>>>>>>>>>> Whats odd is that one guy was getting it on his iPad consistently and
>>>>>>>>>>> when we asked him to try his desktop he's got the same problem on
>>>>>>>>>>> Firefox on Mac. We initially though it might have been a browser
>>>>>>>>>>> issue. We then got another user who got it only once on Chrome on
>>>>>>>>>>> windows - all in the space of 1 day. We're worried that's it happening
>>>>>>>>>>> more often but users are not reporting the issue.
>>>>>>>>>>>
>>>>>>>>>>> Of course we cannot reproduce the issue, but its definitely happening.
>>>>>>>>>>>
>>>>>>>>>>> So you don;t think the shared resource could effect the threads in any way?
>>>>>>>>>>>
>>>>>>>>>>> Where can I start looking in the wicket code to understand where ajax
>>>>>>>>>>> requests are serviced etc? Is there any where/docs I can find to get
>>>>>>>>>>> started at looking at this? - at least to complete more my
>>>>>>>>>>> understanding of how it all works.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> Wayne
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>>>>>>>>> it may be a content type issue, but it is still weird because the
>>>>>>>>>>>> response is received by the xml http request object, not the browser
>>>>>>>>>>>> directly. strange indeed.
>>>>>>>>>>>>
>>>>>>>>>>>> -igor
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Nov 5, 2010 at 7:51 AM, Wayne W <wa...@gmail.com> wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> has anyone had this issue? We're getting emails from our users that
>>>>>>>>>>>>> sometime when clicking on an ajax link the raw wicket ajax response is
>>>>>>>>>>>>> being rendered on the browser - ie the just see all the html source
>>>>>>>>>>>>> code on the page. Its not any particular page.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyone seen this or has any ideas?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only thing we have changed recently was adding a non blocking file
>>>>>>>>>>>>> download using a link and a shared resource which could be related due
>>>>>>>>>>>>> to the Content Type.
>>>>>>>>>>>>> In the configureResponse of the shared resource that we set the
>>>>>>>>>>>>> Content Type for that request. Is there any chance that this is
>>>>>>>>>>>>> somehow polluting the other threads requests?
>>>>>>>>>>>>>
>>>>>>>>>>>>> public class DownloadFileResourceReference extends ResourceReference {
>>>>>>>>>>>>> public DownloadFileResourceReference() {
>>>>>>>>>>>>> super(DownloadLink.class, "");
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> private static final long serialVersionUID = 1L;
>>>>>>>>>>>>>
>>>>>>>>>>>>> public Resource newResource() {
>>>>>>>>>>>>>
>>>>>>>>>>>>> Resource r = new Resource() {
>>>>>>>>>>>>> private static final long serialVersionUID = 1L;
>>>>>>>>>>>>>
>>>>>>>>>>>>> public IResourceStream getResourceStream() {
>>>>>>>>>>>>>
>>>>>>>>>>>>> Long id = getParameters().getLong(DownloadLink.DOCID);
>>>>>>>>>>>>> // get file
>>>>>>>>>>>>>
>>>>>>>>>>>>> return new FileResourceStream(new File(file.getAbsolutePath()));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> protected void configureResponse(Response response) {
>>>>>>>>>>>>>
>>>>>>>>>>>>> Long id = getParameters().getLong(DownloadLink.DOCID);
>>>>>>>>>>>>>
>>>>>>>>>>>>> // get file
>>>>>>>>>>>>>
>>>>>>>>>>>>> ((WebResponse) response).setAttachmentHeader(df.getFileName());
>>>>>>>>>>>>>
>>>>>>>>>>>>> String mimeType = ResourceHelper.getContentType(df.getFileName());
>>>>>>>>>>>>> if (!StringUtils.isEmpty(mimeType)) {
>>>>>>>>>>>>> ((WebResponse) response).setContentType(mimeType);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> };
>>>>>>>>>>>>> r.setCacheable(false);
>>>>>>>>>>>>> return r;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ajax response render as source in the browser
Posted by jgormley <jo...@networkedinsights.com>.
I know this thread is old, but I had this issue and figured out what was
happening in our case. We are using Wicket's client info component (to get
the user's local timezone). If the ajax call is the first to make this
request, then the response page is actually the javascript page that wicket
generates for gathering this information. The javascript page then
redirects to the original request (which happens to be the ajax call), which
then renders in the browser and not in the ajax response.
final ClientInfo info = Session.get().getClientInfo();
The solution was to move this getClientInfo() call into the page, which
forces the javascript page to render prior to the page and not in the ajax
call.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-response-render-as-source-in-the-browser-tp3028722p4385693.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org