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