Re: Problem with the JMeter HTTP Proxy

2010-09-07 Thread Matthias Wessendorf
Felix, Jose_,

I ran into a similar issue - now I filed this ticket:

https://issues.apache.org/jira/browse/TRINIDAD-1905

-Matthias

On Fri, Jan 8, 2010 at 10:48 AM, Jose_ jagavi...@gmail.com wrote:

 Hello Felix, I'm having the same error. I'm testing a JSF application and
 there is a point where it is necessary to send a file with the request. I
 have test it with Internet Explorer and it works fine but, when I test it
 through the JMeter Proxy it doesn't work. I get the same page and the
 following exception:

 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl
 beginRequest
 GRAVE:
 java.io.IOException
        at
 org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:208)
        at
 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:119)
        at
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:523)
        at
 org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:209)
        at
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:142)
        at
 org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
        at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
 org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
        at
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
        at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
 org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
        at
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
        at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
 org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
        at
 org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
        at
 org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
        at
 org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)


 I have debugged the trinidad code and I have discovered what it is happening
 but I don't know how to work it out. Trinidad code seems to expect an empty
 line after a content-type header but JMeter doesn't send a empty line, it
 sends the content-transfer-encoding.

 Maybe it is a trinidad bug, I don't know. I found this interesting post:

 http://markmail.org/message/v2brfsmz257uppy6

 Have you solved your problem? How? Have you got any new idea?

 Thank you


 Felix.Becker wrote:

 Hi!



 We are currently testing our application frontends with Jakarta JMeter
 2.3.2. We are activating the JMeter proxy for creating our Tests. This
 worked fine until we switched the tr:form usesUpload=false to
 tr:form usesUpload=true in our jsf documents. With the Internet
 Explorer it works without the proxy. When the request is send through
 the JMeter proxy, it does not work anymore (I'm getting the same page,
 the actions which should have been triggered were not executed).



 I sniffed with Wireshark and found the POST Request with and without the
 JMeter proxy.


 In the withoutproxy.txt I connected directly to the frontend with the
 IE, in the withproxy.txt it used the JMeter proxy.



 I think the two POST requests are almost the same (HTTP 1.0 / 1.1 should
 not cause an error). Is it possible that a trinidad bug is causing this
 behaviour?



 Any ideas / suggestions?



 Thank you,



 Felix


 POST /xxx_frontend/pages/add.xhtml HTTP/1.0
 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/x-shockwave-flash, application/vnd.ms-excel,
 application/vnd.ms-powerpoint, application/msword, */*
 Referer:
 http://xxx/xxx_frontend/pages/add.xhtml?nodeId=addConfiguration10881285
 Accept-Language: de
 Content-Type: multipart/form-data;
 boundary=---7d81fa171f03e0
 UA-CPU: x86
 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1;
 .NET CLR 1.1.4322; .NET CLR 2.0.50727)
 Host: xxx
 Content-Length: 1586
 Connection: Keep-Alive
 Pragma: no-cache
 Cookie: 

Re: Problem with the JMeter HTTP Proxy

2010-01-08 Thread Jose_

Hello Felix, I'm having the same error. I'm testing a JSF application and
there is a point where it is necessary to send a file with the request. I
have test it with Internet Explorer and it works fine but, when I test it
through the JMeter Proxy it doesn't work. I get the same page and the
following exception:

org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl
beginRequest
GRAVE: 
java.io.IOException
at
org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:208)
at
org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:119)
at
org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:523)
at
org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:209)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:142)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)


I have debugged the trinidad code and I have discovered what it is happening
but I don't know how to work it out. Trinidad code seems to expect an empty
line after a content-type header but JMeter doesn't send a empty line, it
sends the content-transfer-encoding.

Maybe it is a trinidad bug, I don't know. I found this interesting post:

http://markmail.org/message/v2brfsmz257uppy6

Have you solved your problem? How? Have you got any new idea?

Thank you


Felix.Becker wrote:
 
 Hi!
 
  
 
 We are currently testing our application frontends with Jakarta JMeter
 2.3.2. We are activating the JMeter proxy for creating our Tests. This
 worked fine until we switched the tr:form usesUpload=false to
 tr:form usesUpload=true in our jsf documents. With the Internet
 Explorer it works without the proxy. When the request is send through
 the JMeter proxy, it does not work anymore (I'm getting the same page,
 the actions which should have been triggered were not executed).
 
  
 
 I sniffed with Wireshark and found the POST Request with and without the
 JMeter proxy.
 
 
 In the withoutproxy.txt I connected directly to the frontend with the
 IE, in the withproxy.txt it used the JMeter proxy.
 
  
 
 I think the two POST requests are almost the same (HTTP 1.0 / 1.1 should
 not cause an error). Is it possible that a trinidad bug is causing this
 behaviour?
 
  
 
 Any ideas / suggestions?
 
  
 
 Thank you,
 
  
 
 Felix
 
 
 POST /xxx_frontend/pages/add.xhtml HTTP/1.0
 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/x-shockwave-flash, application/vnd.ms-excel,
 application/vnd.ms-powerpoint, application/msword, */*
 Referer:
 http://xxx/xxx_frontend/pages/add.xhtml?nodeId=addConfiguration10881285
 Accept-Language: de
 Content-Type: multipart/form-data;
 boundary=---7d81fa171f03e0
 UA-CPU: x86
 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1;
 .NET CLR 1.1.4322; .NET CLR 2.0.50727)
 Host: xxx
 Content-Length: 1586
 Connection: Keep-Alive
 Pragma: no-cache
 Cookie: JSESSIONID=7A6B3F16F83B1645EAF0B1743DCEDF55;
 oracle.uix=0^^GMT+2:00
 
 -7d81fa171f03e0
 Content-Disposition: form-data; name=nfaddform:nfname
 
 test