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 2010/11/05 15:51:47 UTC
Ajax response render as source in the browser
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
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
Re: Ajax response render as source in the browser
Posted by Wayne W <wa...@gmail.com>.
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 Wayne W <wa...@gmail.com>.
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 Wayne W <wa...@gmail.com>.
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 Dan Retzlaff <dr...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Wayne W <wa...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Dan Retzlaff <dr...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Igor Vaynberg <ig...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Wayne W <wa...@gmail.com>.
> 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
Re: Ajax response render as source in the browser
Posted by Igor Vaynberg <ig...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Wayne W <wa...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Igor Vaynberg <ig...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Wayne W <wa...@gmail.com>.
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
Re: Ajax response render as source in the browser
Posted by Igor Vaynberg <ig...@gmail.com>.
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