Skip to Content
Author's profile photo Former Member

HTTP dirty talks #1


Just not long ago I mentioned the importance of keeping your Get your free I(E)Tunes, well now you can see it pays off. MS published a new patch for IE6 which solves slow web browser performance when browsing pages with JavaScript code. Tests show varied improvement from 0% and up to 50% depending on the exact scenario. I recommend installing it… enjoy.


Now let’s go back to why we are here in the first place – client side tracing. By now your IE should be Get your free I(E)Tunes, patched with the latest fix and you installed a Tools of the trade – improve portal performane using browser tracing tools. I will use HTTPWatch today, but any tool should show you similar results.

Why is it so important?
Sometimes during this simple process you discover many errors and problems that needs to be attended, you won’t find them otherwise. This tracing is important if your users are within the LAN, if they are browsing via WAN – I think skipping it is not even an option.
The main two goals you want to achieve are:
* reducing the number of network roundtrips (utilize the browser cache)
* reducing network traffic (get the request/response as thin as possible)

This is your recipe for true happiness (oh, just after world peace and good health of course).


How do we start?

Choose a simple scenario:
Your scenario should preferably involve one click/navigation step, it’s easier to isolate the problems this way.

Clear the cache, and warm up the browser:
You want to record the http traces when the browser cache is full, this is usually your common scenario. BUT, before you start measuring you better clear the cache once and perform your scenario to warm-up the browser and populate the cache, this will remove old resources you don’t need any more.
*Tip – in IE6 If you browse to some page, clear the cache and at the end click the “OK” button the browser will immediately reload the page to cache. If you click “Cancel” it will not load it…  just good to know.

Record your trace:
Go to the page you want to start from (for example the login page), click the record button in the tracing tool, perform your navigation in the browser, when the page is fully loaded stop recording. That’s it! Save the trace so you can also reference it later and you can start your analysis.

I suggest doing it in a few steps and not everything at once. First clear out the obvious problems (usually errors) then get a better understanding of what is being called and repeat the tracing.


Choose your enemy – response codes
The first thing you look for is the response codes of the server responses, this will give you a quick view of your status. You can find it either in the “Result” column or in the first line of the server response headers.


response codes in HTTPWatch


The common values are:

Cached – this resource is cached on your browser, the request is not sent to the server and you will not see this request in the http logs. The browser fetches this resource locally from its internal cache.

200 (OK) – if your resource is not cached this is what you prefer to have. 200 means OK, the server behaves normally by sending back the resource you requested.

302 (Found) – this actually means a redirect. What happens is that you request some URL and the server send you back a new URL, now the browser sends a new request to the newly received URL. This is bad, very bad. You pay double the price here, Instead of one roundtrip you get 2. The common situations for this is during login (redirect to some authentication service), redirecting to external content such as dotNet or if you have a “nice looking” URL for your portal and it redirects to the actual “ugly” URL. If you can avoid this situation it is preferred… otherwise, everything has its price.

Below you can see an example for 302 response (highlighted with the mouse) and the corresponding “Location” header. Note that the response body is empty (“Content-Length: 0” header), no actual content is returned except for the URL in the header.


302 response example


304 (Not Modified) – This is one vicious performance killer and worth a few more words, it is usually related to cache configuration problems. Your browser is smart, it prefers to use its cache over sending new requests to the server BUT what happens when it is not sure the cache is still valid? It sends a “conditional request”, this is a small request for the resource with the last time it was changed, if the server decides your copy is still valid it returns an empty response with 304 code and the browser will fetch the resource from its cache. It also happens right after the cache lifetime period is over or when it is absent. We will get more into it next time when we discuss http headers.

401 (Unauthorized) – or in other words your authentication failed/missing. This is something you definitely don’t want to see.  You can now check the URL that returned it and check what is wrong here.

 403 (Forbidden) – stop in the name of the law! surprise, surprise, you are trying to view content that you are not authorized to see. naughty you!  Similar to the above 401 response (same-same but different), check the URL and either extend the permissions or remove this resource from the page.

404 (Not Found) – the resource is not located where you expect it to be and the server can’t find it. Sometimes it is a missing image that wasn’t deployed, sometimes it is a typo in the html – in any case this is a problem that is easy to fix, find the missing resource and put it in the right location.

500 (Internal Server Error) – You have a problem, or better said – your server has a problem. Something is very wrong with this request on the server side. Probably you can find some errors in the log files…  

503 (Service Unavailable) – The service is not available. In many cases it means that the service you requested is still initializing and not fully started yet.

If you are curious about other response codes you can find the complete list of HTTP response codes in rfc 2616.


A simple example from the SDN site

by now you probably say “oh well, how bad can it be? Does it really worth the effort?”, they say a picture worth a thousand words, so watch what I marked in red below:


304 response example


What do you see?
This is a trace I took while browsing the SDN from my desktop in IL.
The first marked file from the top is of type image.gif, it is a simple gif file that the browser loads from cache (you can see the “(Cached)” value in the results column). Time estimation for retrieving it is 0.002 sec. sounds reasonable, isn’t it?
Now watch the marked file below to see what happens when the cache is not sure if it has an updated version of a file – it sends an “if-modified-since” conditional request, the server receives the request and verifies the time stamp of the file and decides that the file did not change. The server now sends a 304 response code and the browser ends up retrieving the image.gif file from the cache. Total time for retrieving the file is 0.717 sec. almost a full second for a small gif file. And I want to stress this – both files were eventually loaded from the browser cache!
 You wonder what is this important gif file? If you click on my name at the beginning of this post and get to my list of posts, see this small SAP icon at the right side of my name? BINGO! Almost 1 second of your life… you should give this icon more respect now.
While you are here, why not clicking on my previous blogs or leave me a nice message? Support my effort, you know.

What’s next?
You have now about 2-3 weeks to get experienced with your favorite tracing tool and check all those missing files, bad permissions etc. I will use this time to write the next post, where I will show you how to understand the http headers and use the HTTP configuration options on the server to eliminate the 304 responses, along with other tuning tips.


Until next time,

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I'd say that some of the status code descriptions are very misleading.

      A few examples:

      302: this may be totally by design, for instance for links inside KM.

      304: it's bad because it didn't use the cache. But it's goood, as the content actually didn't need to be retrieved. If a resource is known to change from time to time, you simply can't avoid that the client needs to recheck it from time to time.

      401: perfectly normal for the first request, before authentication. And it's totally different from 403 -- 401 means you need to authenticate, 403 means you're not allowed to do what you want to do even though you are authenticated.

      BR, Julian

      Author's profile photo Former Member
      Former Member
      Hi Julian,
      Thank you for stressing these important points. I can’t get too deep into these topics in the post but I will try to explain what I meant.

      302, 401 etc can be part of your pages design; I even encountered a 500 response code that was used as a tweak to add some functionality (not my cup of tea). This may be perfectly fine or an error that needs to be identified. I try to encourage users to get more familiar with their scenario and reveal the “magic” behind the scenes.
      Also for the case of 304, there may be cases where it can’t be avoided but in many other cases it is just a matter of configuration tuning.
      At the end of the day everything has its price, especially on WAN scenarios. 304 does not have a body (so does 302) but you still pay the price of network roundtrip. If you have a bad line and 20 304 requests it can take the page 20-30 seconds to load, which makes it unusable (I actually saw this scenario more than once).
      Thanks, yoni.

      Author's profile photo Former Member
      Former Member
      304 - If a resource is known to change from time to time, you simply can't avoid that the client needs to recheck it from time to time. I agree. But if the resource is available in browser cache and still has a valid expiration date/time, why browser continues to send server request to check if resource is still valid?
      Author's profile photo Former Member
      Former Member
      Hi John,
      There may be several reasons for getting 304 when the resource is in browser cache, I can give few real-life examples that I have encountered (don’t remember all of them).

      Wrong time settings on the server/client – if the server or client machines are not configured with the right time and time zone it may cause wrong calculation of the expiration time. I once saw a server that constantly went out of tune and the date/time settings reset after every restart. It took some time to find out that the backup battery on the motherboard was dead. true story.

      Browser cache algorithm – you can configure your IE to use one of several cache algorithms. If you configured it to check for new version every time you visit a page it will force the 304 even if the expiration is still valid, I published a short post about IE configuration few weeks ago.

      Using the refresh button (or F5) – if you use the refresh button on a page it should revalidate the resources versions even if they are still valid. This will result in many 304 responses.
      BTW, using CTRL+F5 will force the browser to ignore the cache and reload the page all over again (you get 200 results).

      I noticed that sometimes resources that don’t have any caching headers may be cached and the browser will send an if-modified-since request as an optimization.

      Browser cache behavior has always been a mystery; MS does not provide info about its decision algorithm so we can only guess, it may also vary from one browser version to another.

      Thanks, yoni.

      Author's profile photo Madhu Bandireddy
      Madhu Bandireddy
          Eversince we applied this Microsoft patch we are getting a number of "page not displayed" errors when we access ABAP WebDynpro applications (iViews) through our Portal. This happens especially when we try accessing the ABAP WebDynpro iView pages from the outside.
      Almost all the failures are on POST requests. All of them seem so have a Content-Length of 0.
      When we click twice on any of the WD4A iViews the screen does render but when we try to go back to it, we see the same error page again. We have an OSS message open with SAP on this. This problem seems to be independent of whether we use HTTP or HTTPS (all the way). Does not seem to matter whether we use IE6 or IE7. We have sent HTTPWATCH logs and a number of other traces to OSS.  We have changed timeout settings per OSS processor as per note 900804 and applied Microsoft KB article 921090.

      We are on NW04s SP13 and ICM patch 140. Kernel patch is 141.

      Have you seen this problem before and do you know of a potential solution?

      Appreciate your help.


      Author's profile photo Former Member
      Former Member
      Hi Madhu,

      Thank you for this important feedback, I didn’t hear of any problem so far but I’m looking into it and inquire colleagues to see if anyone came across such a problem. The patch that was released for IE6 includes a fix that already exists in IE7 so it is expected that you see the same behavior.
      Can you send the OSS number/subject so I can look for more details?
      I will update you as soon as I get more info.


      Author's profile photo Former Member
      Former Member
      Hi Madhu,

      So far I didn’t encounter any problems with the fix.
      Can you check if one of the following KB articles is relevant?


      Author's profile photo Former Member
      Former Member
      One of the developers found a potential problem with IE patch – it seems that certain security patch removes old JRE version (JER1.3). In that case, after the patch is installed, you remain without a JRE installed (but the registry references still exist) so apps that require applets will fail. It doesn’t happen if you have a current JRE version installed and it is easily solved by installing the latest JRE from


      Author's profile photo Former Member
      Former Member

      I am a beginner using/monitoring XI.  We are using XI 3.0 and I just got slammed with some RWB-Error at Integration Engine emails.  When I checked SXI_Monitor-there are 46 System Error messages with the follow Trace:Help


      500 Connection timed out

      Connection timed out (-5)

      Error: -5
      Version: 6040
      Component: ICM
      Date/Time: Mon Dec 15 11:21:48 2008
      Module: icxxthr_mt.c
      Line: 2603
      Server: pcfpro06_PMS_10
      Detail: Connection to partner timed out after 60s
      © 2001-2005, SAP AG

      </FONT></td></tr></table></SAP:AdditionalText> <br/>  <SAP:ApplicationFaultMessage namespace="" /> <br/>  <SAP:Stack>HTTP response contains status code 500 with the description Timeout Error when sending by HTTP (error code: 500, error text: Timeout)</SAP:Stack> <br/>  <SAP:Retry>M</SAP:Retry> <br/>  </SAP:Error><br/><br/><br/>I tried to manually restart them; however, they erred out again.  I've been trying to research this but can not find any solution.  Any help/suggestions/directions would be greatly appreciated.<br/><br/>Kim Selby

      Author's profile photo Former Member
      Former Member
      Hi Kim,

      I’m not too familiar with XI but from the error description it seems that the integration server initiated a request to other service and then encountered a TimeOut, which in turn caused the server to fail the processing of the request and respond with 500 response code (internal server error).
      The error states that the timeout was triggered after 60 seconds so you can change the timeout configuration to more than 60sec and see if this solves the problem – either in the ICM configuration or in VisualAdmin-> HTTP provider. There may be specific timeout configuration to your application (XI), but I don’t know it enough to say.
      There may be few reasons for timeout, the most frequent ones are bad network or the time it takes the service to process the request and produce the response.
      If the errors persist you can trace the requests that triggered it and check if they require a lot of processing, then you can change them to “lighter” requests and see if it changes anything.

      Hope it helps,
      Cheers, Yoni