Skip to Content

<body><p> </p><p>Reminder – If you are reading this post before reading my previous ones I kindly ask you to go back and read the first ones first… I’m trying to lead you through a process. Thanks :)) </p><p>So by now everything looks a little brighter – the browser is set, you have a browser tracing tool and you have seen how things looks like from your end. Hopefully (or not…) you spotted some problems and fixed them already. Never thought there is so much action behind the scenes? We are just getting started. </p><p>Today we will dive deeper into the http traces and learn some more about the client-server dialog, as well as some tuning tips on the server side that might save you some time.</p>h3. Into the deep water

<p>The http spec defines many different header names that can be used, most of them were defined in http spec version 1.0 but some are only introduced in http 1.1 spec. To add to the confusion, some of the headers are explicit (meaning you specifically define what behavior you want) and some of them have implicit meaning (you get some behavior as result of other header you defined). Add to the equation the browser version factor and you get a nice cocktail that will certainly give you a headache. You think you are bigger than that? You will be knocked down when proxy servers joins the party. Don’t tempt me. </p><p>Unfortunately (and luckily for you) I won’t be able to cover all headers or different combinations, the spec is unbelievably long and far from being easy to read or understand. I will refer to the common scenarios and naïve interpretation of the spec, I know there are always exceptions and special cases – want to share one? this is why we have the “comments” section at the bottom. <br />Let’s take an example and analyze it.</p><p>You know by now how to take HTTP traces, I will continue to use HTTPWatch for the demonstration – to see the headers of the request and response you should click the URL and navigate to the “Headers” tab. See image below.</p><p> </p><p><img  />//|height=384|alt=httpwatch headers tab|width=598|src=|border=1!</p><p> </p><p>Usually the headers are separated by line breaks and looks like <header name>: <header value> but in this tab they are displayed more conveniently (for raw data go to “Stream” tab).<br />The spec defines which values are possible for every header name.</p><p> So let’s review the more important headers.</p><p>Consider the below headers, this is the Login post:

POST /irj/servlet/prt/portal/prteventname/Navigate/../.. HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, /

Referer: http://localhost:53000/irj/portal?…

Accept-Language: en-us

Content-Type: application/x-www-form-urlencoded

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)

Host: localhost:53000

Content-Length: 298

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: PortalAlias=portal; saplb_*=(ilperf125_F37_30)303540750; …

POST /irj/servlet/prt/portal/prteventname/Navigate/../.. HTTP/1.1<br />First line says POST or GET, which is the http method we use, following by the requested URL and then HTTP/Referer: http://localhost:53000/irj/portal  (http://localhost:53000/irj/portal)?…<br />Who triggered this request; this is useful in case you want to trace which file caused this request to be sent.

Accept-Encoding: gzip, deflate<br />the browser explicitly specifies that it support gzip data compression, so the server can compress the response body. Just to clear things out – a) it is up to the server to decide if it wants to compress or not, b) the http headers themselves can’t be compressed; you need the headers to tell the browser that the body is actually compressed.

Cache-Control: no-cache<br />in this case the browser requests that the request-response will not be cached. This is normal for POST since it involves with submitting parameters that needs to be processed on the server.

Connection: Keep-Alive<br />this means that the browser will reuse the connection after it receives the response, unless the response specifies otherwise (like Connection: close).

+Cookie: PortalAlias=portal; saplb_=(ilperf125_F37_30)303540750; …

+On every request the browser sends the complete list of cookies that are relevant to that domain. Remember I said that the headers can’t be compressed? This is a major downside for cookies since they can be very long (and could have been easily compressed since they are textual).</p><p>And now let’s go the server response (headers received by the browser):*

HTTP/1.1 200 OK

Server: SAP J2EE Engine/7.00

Content-Type: text/html; charset=UTF-8

Content-Language: en-US

Content-Encoding: gzip

Date: Mon, 21 Jan 2008 15:29:24 GMT

Transfer-Encoding: chunked

HTTP/1.1 200 OK<br />The server responds* with the response code (talked about it last time) and the http version it supports.</p><p>Content-Type: text/html; charset=UTF-8<br />the content type of the returned body, In our case this is html file. </p><p>Content-Encoding: gzip<br />the content is compressed. In httpwatch under the “stream” tab you can see the raw request and response. If you look below the headers you will see gibberish – this is the actual compressed content (binary data). Go to the “content” tab and you will see the body after it was decompressed.</p><p>Date: Mon, 21 Jan 2008 15:29:24 GMT

The date and time this message was originated.</p><p>Transfer-Encoding: chunked<br />the server does not provide total response length.

</p><p>Let’s see another example – this is a response of resources that should be cached:*

HTTP/1.1 200 OK

Server: SAP J2EE Engine/7.00

Content-Type: application/x-javascript

Last-Modified: Tue, 01 Jan 2008 09:40:19 GMT

Cache-Control: max-age=86400

Content-Length: 69729

Date: Wed, 23 Jan 2008 15:44:59 GMT

What is the difference here?<br />You can see the content type header that indicates this is a javascript file, and the cache control returns with a “max-age=86400” value. This means that the server tells the browser it should cache it for 86,400 seconds, which are 24 hours. From now on, for the next 24 hours the browser can load this file from cache whenever it is requested with no need to request it from the server again.

What happens when the 24 hours are over?

The server sent an additional header “Last-Modified“, this is the date when the requested resource was last modified on the server. The browser saves this date together with the cache definitions of the file and when the cache period times-out it sends a conditional request to the server asking if the resource was modified or not. If the resource was modified the server will send the updated resource file and replace the cached version, if not – the browser will send a short response that indicates the browser to continue using the cached file (and continue to cache it for the next 24 hours).

What can you do to improve performance?

The http server allows you to configure many parameters, you should check what is configured and make sure to have the best matching configuration for your needs.


Use the VisualAdmin tool. Go to Server_abc -> services -> HTTP Provider service

On the Runtime tab you see the following 4 options, make sure they are properly configured.


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Sean M
    Thanks for this series. It’s nice to know I’m not the only who has to go read the protocol spec :-).

    Your point about testing the effectiveness of the compression is well taken. There is (at least) a blog’s worth of material on that detail alone, but just to expand a bit:
    1) a LAN case where compression may not help is where the network is fast, but the desktops are older models (where the page rendering is CPU-bound rather than I/O bound).
    2) as you wrote, don’t compress content that is already compressed, like GIF/JPG images or ZIP/GZIP/Z files (but *do* compress BMP images!). Recompression is very slow (because it can’t find short repeated blocks) and doesn’t gain anything. So get to know your filetypes.
    3) Web acclerators are becoming more common, especially in WAN scenarios. These are dedicated appliances at the server end of the line (it’s a next-gen SSL accelerator), for compression, caching, and even delta-detection (so that you only get the changed content when you refresh at the browser). Do not do ANY compression at the portal server in that scenario, since the appliance will have to uncompress before it can do its thing. Eliminating that unnecessary compression/decompression greatly reduced the latency with the appliance I tested.
    4) a while back I had problems with links to launch MS Office documents not working properly because of compression (that may be fixed now).


    P.S. it’s probably worth mentioning another difference between HTTP 1.0 and 1.1, is that the host is required in the request header in 1.1 but not 1.0.  Of course that’s related to the proxy headaches you mentioned. If you’re messing around at the protocol level, it’s nice to keep 1.0 in your pocket, to avoid having to change the host name on the fly.

    1. Yoni Mizrachi Post author
      Hi Sean,
      Thank you, these are important points that you raise.
      It looks like you sure know your files! I won’t even ask why you need to know the BMP format, I guess everyone has skeletons in their past :))… 

      Among the network accelerators I can’t resist mentioning our own ADoW (Application Delivery over WAN), which will soon come bundled with every portal installation. Like Juniper and other devices it also handles compression, so in that case you should know your solution architecture for best configuration.



Leave a Reply