Bug 52061 - Allow access to Request Headers in Regex Extractor
Summary: Allow access to Request Headers in Regex Extractor
Status: RESOLVED FIXED
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 2.11
Hardware: PC Windows XP
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2011-10-20 08:08 UTC by Sebb
Modified: 2014-08-18 13:23 UTC (History)
2 users (show)



Attachments
patch (43.85 KB, patch)
2013-05-30 12:58 UTC, Dzmitry Kashlach
Details | Diff
RegexExtractor w\o formatting mess (12.50 KB, patch)
2014-07-31 08:33 UTC, Dzmitry Kashlach
Details | Diff
RegexExtractor: reverted USE_HDRS (5.47 KB, patch)
2014-07-31 11:44 UTC, Dzmitry Kashlach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sebb 2011-10-20 08:08:41 UTC
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.
Comment 1 Dzmitry Kashlach 2013-04-11 14:16:19 UTC
 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.
Comment 2 Sebb 2013-04-12 00:09:00 UTC
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
Comment 3 Dzmitry Kashlach 2013-05-30 12:58:34 UTC
Created attachment 30343 [details]
patch

Sebb,

 Please, review patch for this issue.
Comment 4 Sebb 2013-05-30 15:52:33 UTC
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$
Comment 5 Dzmitry Kashlach 2014-07-31 08:32:17 UTC
(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?
Comment 6 Dzmitry Kashlach 2014-07-31 08:33:45 UTC
Created attachment 31862 [details]
RegexExtractor w\o formatting mess
Comment 7 Sebb 2014-07-31 10:14:29 UTC
(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.
Comment 8 Dzmitry Kashlach 2014-07-31 11:44:16 UTC
Created attachment 31863 [details]
RegexExtractor: reverted USE_HDRS

Ok, clear. 
Reverted USE_HDRS back.
Please, check.
Comment 9 Sebb 2014-07-31 12:42:44 UTC
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.
Comment 10 Sebb 2014-07-31 13:26:06 UTC
(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
Comment 11 Dzmitry Kashlach 2014-07-31 13:28:58 UTC
Thanks, I've noticed.
Comment 12 Sebb 2014-08-18 13:23:02 UTC
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