In general, request headers should be "known" to the test plan, so it does not seem necessary to provide access from PostProcessors such as the Regex Extractor. However, there are some request fields that are generated internally (e.g. cookies, JMS messageId - Bug 52054) so it makes sense to allow access to the headers in PostProcessors.
Sebb, What other PostProcessors except RegularExpressionExtractor are supposed to have access to Request headers? I think, no sense to implement this for CSS/Jquery or XPath extractor. So, only RegExpEx-tor? P.S. I'm asking, because I'll try to implement this.
It does not make sense for XPath etc because the headers don't have the correct structure. However, it might be useful to the BSH/BSF PostProcessors
Created attachment 30343 [details] patch Sebb, Please, review patch for this issue.
Thanks for the patch. I've had a quick look, and there seem to be quite a few formatting changes and changes to import layout. Please only change the minimum needed to implement the feature. It's difficult to review the patch properly (and will be difficult to review the SVN diff mail later) if the patch contains spurious changes. One problem I did notice amongst the noise is that it renames a public constant [1] (and changes the value). That will break existing test plans. [1] public static final String USE_HDRS = "true"; // $NON-NLS-1$
(In reply to Sebb from comment #4) > One problem I did notice amongst the noise is that it renames a public > constant [1] (and changes the value). That will break existing test plans. > [1] public static final String USE_HDRS = "true"; // $NON-NLS-1$ Hi Sebb, Sorry for not answering for so long. Yes, I agree about comment regarding reformatting: this was just default settings of IDE. Attached cleaned patch. Can you help with a question about "public static final String USE_HDRS = "true";? If we have two radio-buttons for headers(Resp. Headers and Req. Headers), we need to differ them somehow from each other and other radio-buttons. I see, that other variables have not only "true/false" value, but strings. public static final String USE_BODY_UNESCAPED = "unescaped"; // $NON-NLS-1$ public static final String USE_BODY_AS_DOCUMENT = "as_document"; // $NON-NLS-1$ So, I'd suggest to change name/values of variables to: public static final String USE_RESPONSE_HDRS = "response_headers"; // $NON-NLS-1$ public static final String USE_REQUEST_HDRS = "request_headers"; // $NON-NLS-1$ You're right, that changing this variable involves changing unit-tests. The only test-suite, where this variable is used is TestRegexExtractor in public void testVariableExtraction7()(line 229). Can I also adjust test-suite according to changes?
Created attachment 31862 [details] RegexExtractor w\o formatting mess
(In reply to Dzmitry Kashlach from comment #6) > Created attachment 31862 [details] > RegexExtractor w\o formatting mess Sorry, but the patch still has unnecessary changes to imports. Also we don't use wild-card imports, and JVM imports are listed first. Also, the VALUE of the field USE_HDRS is used in test plans. It cannot be changed without breaking existing test plans. Please read the comments before USE_HDRS. Create a test plan using various different settings for the Regex field and compare the entries. You will need to add a new VALUE for USE_REQUEST_HEADERS.
Created attachment 31863 [details] RegexExtractor: reverted USE_HDRS Ok, clear. Reverted USE_HDRS back. Please, check.
That looks a lot better. Note how much smaller the diff is now (5kb compared with 12kb or 44kb). It's also a lot easier to see what is being changed.
(In reply to Sebb from comment #2) > > However, it might be useful to the BSH/BSF PostProcessors They can do this already via the sample response object
Thanks, I've noticed.
URL: http://svn.apache.org/r1614883 Log: Allow access to Request Headers in Regex Extractor Bugzilla Id: 52061 Modified: jmeter/trunk/src/components/org/apache/jmeter/extractor/RegexExtractor.java jmeter/trunk/src/components/org/apache/jmeter/extractor/gui/RegexExtractorGui.java jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2614