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 <igor.vaynb...@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 <waynemailingli...@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 <igor.vaynb...@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 <waynemailingli...@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 <igor.vaynb...@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 <waynemailingli...@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 <igor.vaynb...@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 <waynemailingli...@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-unsubscr...@wicket.apache.org >>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
