In Progress Telerik Fiddler Web Debugger is there a way to adjust Content-Length automatically in AutoResponder? - telerik

I am using fiddler autoresponder to return a different JS file than the one loaded from my server originally. The adjusted file uses:
HTTP/1.1 200 OK
Cache-Control: private, max-age=31536000
Content-Type: application/javascript
...other headers
Content-Length: 37010
...the javascript code
At the top of the file, this Content-Length header is not automatically adjusted to the edited file though. So I have to try and load my changes, my app will crash because the Content-Length is wrong, but then I check fiddlers 'transformer' tab to see how many bytes my request body actually is, update that in my modified file, refresh again and then it works.
I have tried to change the encoding to chunked, so that I could leave out the Content-Length header, but I don't think my app knows how to decode chunked for some reason.
So my question is, is there any way to automatically update the Content-Length in the auto-responder?

You can simply use FiddlerScript in Fiddler classic to build your auto responder. That way the content-length is set automatically:
static function OnBeforeRequest(oSession: Session) {
// ... some other FiddlerScript code
// host is e.g. "localhost:3000"
if (oSession.HostnameIs("<host>") && oSession.uriContains("<file name>.js")) {
oSession.utilCreateResponseAndBypassServer();
oSession["ui-backcolor"] = "lime"; // Makes it more visible
if (!oSession.LoadResponseFromFile("<file path>.js")) {
throw new ApplicationException("LoadResponseFromFile Failed!! ");
}
// Just loads forever if Content-Length is not added
oSession.oResponse["Content-Length"] = oSession.responseBodyBytes.GetLength(0);
}
}

Related

Getting Jmeter to generate the boundary dashes in the Content-Type header (eg boundary=--V0a4bfux...)

This what my HTTP request is generating
Content-Type: multipart/form-data; boundary=V0a4bfuxfGhaH_Voo_Gu6oAEtj5FJNcp; charset=UTF-8
However, when compared to the POST data, it is lacking the 2 dashes in the front, which causes the server to reject the request:
--V0a4bfuxfGhaH_Voo_Gu6oAEtj5FJNcp
Content-Disposition: form-data; data="dataToBeSent"
--V0a4bfuxfGhaH_Voo_Gu6oAEtj5FJNcp--
How do I get Jmeter to generate the dashes in the header?
(besides from manually creating the multipart form)
Note:
I am using the 'Use multipart/formdata for POST' option.
If I intercept the request and manually add the dashes in the header, the
server accepts the request.
You don't need to generate these values, the solution is to tick Use multipart/form-data for POST box in the HTTP Request sampler (or in the HTTP Request Defaults)
If you have any definition of Content-Type header in the HTTP Header Manager - you need to remove it and let JMeter generate appropriate Content-Type header on its own.
The header doesn't need the dashes. This is simply how multipart/form-data works. The body is built as follows:
--<boundary>
<headers>
<content>
--<boundary>
<headers>
<content>
--<boundary>--
The -- part indicates a new part starts. The body ends with ---- to indicate no new parts will follow.

JMeter Multipart JSON Request Form Data

I am trying to construct a HTTP Request through JMeter that uses a multipart data body.
I have a HTTP Header Manager that has COntent-Type set to multipart/form-data; boundary=AaB03x. I selected 'Use multipart/form-data for POST'.
I then have a data body created as,
`-----------------------------AaB03x
Content-Type: application/json
Content-Disposition: form-data; name="part1"
{"jsonKey1": "JsonValue1" }
-----------------------------AaB03x
Content-Type: application/json
Content-Disposition: form-data; name="part2"
{
"jsonKey2": "JsonValue2"
}
-----------------------------AaB03x
Content-Type: application/octet-stream
Content-Disposition: form-data; name="part3"
File Content here!!!!
-----------------------------AaB03x`
When I run this, I see that the request doesnt send the body correctly, instead it just sends some random data as,
POST data:
--vKOghkU7riRQbaANmmGpMs7j9TxCTUp3S2T0vE--
And gives an error response of,
`{"errorMsg":"Unable read headers from MultipartStream.","messageCode":"UnableReadHeadersFromMultipartStream","httpStat us":"BAD_REQUEST","requestName":"RequestName"}`
My second question is:
the part3 of the request sends a file to upload. Can I pass the file path somehow?
Given you set your own boundary and build your request manually I believe you need to uncheck Use multipart/form-data for POST in the HTTP Request Sampler
If your file encoding isn't very "exotic" you can try using __FileToString() function just instead of File Content here!!!!.
Looking into RFC 7578, it seems you also need a trailing -- at the end of the last line
You should try sending your JSON data as parameters. Also put your file path in the section for that... And even some servers don't actually need MIME type explicitly declared, you can check yours with some online tool like this one.
Your HTTP Request could look smethnig like:

Change Referrer in header using Varnish

I think this is a possiblity with varnish where you can change the referrer in the header of its users and then serve them the content either from cache or from the server. I want to know how can that be made possible.
I tried this with "req.http.referer" and then "set req.http.referer" in varnish 2.1 on centos 32-bit machine but it didn't work when i checked the results with the command "varnishtop -i TxHeader -I Referer".
Anyone got any other ideas better than this?
At least on Varnish 3.0 the following works as expected. Obviously if the response is served from cache and you are not using the req.http.Referer for hash(), it doesn't matter how you change the referer header.
# Modify Referer header
sub vcl_recv {
if (req.http.Referer) {
# Referer was set. Replace foo with bar
set req.http.Referer = regsub(req.http.Referer,"foo","bar");
} else {
# Referer was not set. Set it to something anyway.
set req.http.Referer = "http://referer.was.empty/";
}
}
Also note that varnishtop -i TxHeader -I Referer is case sensitive. If you set req.http.referer then it will not match -I Referer even though your HTTP backend will understand the referer: header as well (according to RFC 2612 4.2 message headers are case insensitive).

caching problem

I wrote one script which is running on the linux machine.It fetches data from one url and displays the content on a page.
The problem I am facing is some time if I refresh the page 4-5 times it displays the old content and not the latest one.
The problem could be because of caching proxy which is still caching old content.
Please tell me what to write in the script which automatically delete the caching proxy.
You should try using the Cache-Control HTTP header in your request, to tell the proxy (if there is one) not to cache the result.
See RFC 2616 for an explanation.
Take a look here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/twbs_cookie.html
and set the following HTTP headers:
Expires with the value a hard coded GMT date in the past
Last-Modified with the value the current date in GMT formatted "EEE, d MMM yyyy HH:mm:ss"
Cache-Control with the following value 'no-store, no-cache, must-revalidate'
Cache-Control with the following value 'post-check=0, pre-check=0'
Pragma with the following value 'no-cache'

Dealing with ISO-encoding in AJAX requests (prototype)

I have a HTML-page, that's encoded in ISO-8859-1 and a Prototype-AJAX call that's build like this:
new Ajax.Request('api.jsp', {
method: 'get',
parameters: {...},
onSuccess: function(transport) {
var ajaxResponse = transport.responseJSON;
alert(ajaxResponse.msg);
}
});
The api.jsp returns its data in ISO-8859-1. The response contains special characters (German Umlauts) that are not displayed correctly, even if I add a "encoding: ISO-8895-1" to the AJAX-request. Does anyone know how to fix this?
If I call api.jsp in a new browser window separately the special characters are also corrupt. And I can't get any information about the used encoding in the response header. The response header looks like this:
Server Apache-Coyote/1.1
Content-Type application/json
Content-Length 208
Date Thu, 29 Apr 2010 14:40:24 GMT
Notice: Please don't advice the usage of UTF-8. I have to deal with ISO-8859-1.
Just found the answer myself. Though this is for PHP I'm sure you can find the equivalent for ASP :)
Basically, just include the encoding header on your response page (in your case api.asp), like this:
header("Content-Type: text/html; charset=ISO-8859-1");
Good luck with it :)
//Jannik Olsen

Resources