jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@apache.org
Subject svn commit: r1457581 [1/3] - /jmeter/trunk/xdocs/usermanual/
Date Sun, 17 Mar 2013 22:58:08 GMT
Author: sebb
Date: Sun Mar 17 22:58:08 2013
New Revision: 1457581

URL: http://svn.apache.org/r1457581
Log:
Tab police - also remove trailing spaces in same files

Modified:
    jmeter/trunk/xdocs/usermanual/best-practices.xml
    jmeter/trunk/xdocs/usermanual/boss.xml
    jmeter/trunk/xdocs/usermanual/build-ldap-test-plan.xml
    jmeter/trunk/xdocs/usermanual/build-ldapext-test-plan.xml
    jmeter/trunk/xdocs/usermanual/component_reference.xml
    jmeter/trunk/xdocs/usermanual/functions.xml
    jmeter/trunk/xdocs/usermanual/get-started.xml
    jmeter/trunk/xdocs/usermanual/index.xml
    jmeter/trunk/xdocs/usermanual/ldapanswer_xml.xml
    jmeter/trunk/xdocs/usermanual/ldapops_tutor.xml
    jmeter/trunk/xdocs/usermanual/listeners.xml
    jmeter/trunk/xdocs/usermanual/remote-test.xml
    jmeter/trunk/xdocs/usermanual/test_plan.xml

Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1457581&r1=1457580&r2=1457581&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
+++ jmeter/trunk/xdocs/usermanual/best-practices.xml Sun Mar 17 22:58:08 2013
@@ -20,7 +20,7 @@
 [
 <!ENTITY sect-num '16'>
 ]>
-	
+
 <document prev="remote-test.html" next="boss.html" id="$Id$">
 
 <properties>

Modified: jmeter/trunk/xdocs/usermanual/boss.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/boss.xml?rev=1457581&r1=1457580&r2=1457581&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/boss.xml (original)
+++ jmeter/trunk/xdocs/usermanual/boss.xml Sun Mar 17 22:58:08 2013
@@ -19,7 +19,7 @@
 <!DOCTYPE document[
 <!ENTITY sect-num '17'>
 ]>
-	
+
 <document prev="best-practices.html" next="component_reference.html" id="$Id$">
 
 <properties>
@@ -55,32 +55,32 @@ cannot locate these resources, <b>you</b
 already have your work cut out for you, it is worth knowing who the following
 people are, so that you can ask them for help if you need it.
 </p>
-	<subsection name="&sect-num;.2.1 Network" anchor="network">
-	<p>Who knows our network topology ? If you run into any firewall or
-	proxy issues, this will become very important. As well, a private
-	testing network (which will therefore have very low network latency)
-	would be a very nice thing. Knowing who can set one up for you
-	(if you feel that this is necessary) will be very useful. If the
-	application doesn't scale as expected, who can add additional
-	hardware ?
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.2.2 Application" anchor="application">
-	<p>Who knows how our application functions ? The normal sequence is
-	<ul>
-		<li>test (low-volume - can we benchmark our application?)</li>
-		<li>benchmark (the average number of users)</li>
-		<li>load-test (the maximum number of users)</li>
-		<li>test destructively (what is our hard limit?)</li>
-	</ul>
-	The <b>test</b> process may progress from black-box testing to
-	white-box testing (the difference is that the first requires
-	no knowledge of the application [it is treated as a "black box"]
-	while the second requires some knowledge of the application).
-	It is not uncommon to discover problems with the application
-	during this process, so be prepared to defend your work.
-	</p>
-	</subsection>
+    <subsection name="&sect-num;.2.1 Network" anchor="network">
+    <p>Who knows our network topology ? If you run into any firewall or
+    proxy issues, this will become very important. As well, a private
+    testing network (which will therefore have very low network latency)
+    would be a very nice thing. Knowing who can set one up for you
+    (if you feel that this is necessary) will be very useful. If the
+    application doesn't scale as expected, who can add additional
+    hardware ?
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.2.2 Application" anchor="application">
+    <p>Who knows how our application functions ? The normal sequence is
+    <ul>
+        <li>test (low-volume - can we benchmark our application?)</li>
+        <li>benchmark (the average number of users)</li>
+        <li>load-test (the maximum number of users)</li>
+        <li>test destructively (what is our hard limit?)</li>
+    </ul>
+    The <b>test</b> process may progress from black-box testing to
+    white-box testing (the difference is that the first requires
+    no knowledge of the application [it is treated as a "black box"]
+    while the second requires some knowledge of the application).
+    It is not uncommon to discover problems with the application
+    during this process, so be prepared to defend your work.
+    </p>
+    </subsection>
 </subsection>
 <subsection name="&sect-num;.3 What platform should I use to run the benchmarks/load-tests
?" anchor="platform">
 <p>This should be a widely-used piece of hardware, with a standard
@@ -119,31 +119,31 @@ become familiar with them. This should i
 appropriate documentation (man-pages, info-files, application --help messages,
 and any supplied documentation).
 </p>
-	<subsection name="&sect-num;.4.1 ping" anchor="ping">
-	<p>
-	This can be used to establish whether or not you can reach your
-	target site. Options can be specified so that 'ping' provides the
-	same type of route reporting as 'traceroute'.
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.4.2 nslookup/dig" anchor="dig">
-	<p>
-	While the <u>user</u> will normally use a human-readable internet
-	address, <u>you</u> may wish to avoid the overhead of DNS lookups when
-	performing benchmarking/load-testing. These can be used to determine
-	the unique address (dotted quad) of your target site.
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.4.3 traceroute" anchor="traceroute">
-	<p>
-	If you cannot "ping" your target site, this may be used to determine 
-	the problem (possibly a firewall or a proxy). It can also be used
-	to estimate the overall network latency (running locally should give
-	the lowest possible network latency - remember that your users will
-	be running over a possibly busy internet). Generally, the fewer hops
-	the better.
-	</p>
-	</subsection>
+    <subsection name="&sect-num;.4.1 ping" anchor="ping">
+    <p>
+    This can be used to establish whether or not you can reach your
+    target site. Options can be specified so that 'ping' provides the
+    same type of route reporting as 'traceroute'.
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.4.2 nslookup/dig" anchor="dig">
+    <p>
+    While the <u>user</u> will normally use a human-readable internet
+    address, <u>you</u> may wish to avoid the overhead of DNS lookups when
+    performing benchmarking/load-testing. These can be used to determine
+    the unique address (dotted quad) of your target site.
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.4.3 traceroute" anchor="traceroute">
+    <p>
+    If you cannot "ping" your target site, this may be used to determine 
+    the problem (possibly a firewall or a proxy). It can also be used
+    to estimate the overall network latency (running locally should give
+    the lowest possible network latency - remember that your users will
+    be running over a possibly busy internet). Generally, the fewer hops
+    the better.
+    </p>
+    </subsection>
 </subsection>
 <subsection name="&sect-num;.5 What other products are there ?" anchor="products">
 <p>There are a number of commercial products, which generally have fairly
@@ -153,37 +153,37 @@ limited budget, the following are worth 
 start by trying the Apache <b>ab</b> tool, as it may very well do the job
 if your requirements are not particularly complicated.
 </p>
-	<subsection name="&sect-num;.5.1 Apache 'ab' tool" anchor="ab">
-	<p>
-	You should definitely start with this one. It handles HTTP 'get' requests
-	very well, and can be made to handle HTTP 'post' requests with a little
-	effort. Written in 'C', it performs very well, and offers good (if basic)
-	performance reporting.
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.5.2 HttpUnit" anchor="httpunit">
-	<p>
-	This is worth a look. It is a library (and therefore of more interest to
-	developers) that can be used to perform HTTP tests/benchmarks. It is
-	intended to be used instead of a web browser (therefore no GUI) in
-	conjunction with <b>JUnit</b>.
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.5.3 Microsoft WAS" anchor="WAS">
-	<p>
-	This is definitely worth a look. It has an excellent user interface
-	but it may not do exactly what you want. If this is the case, be aware
-	that the functionality of this product is not likely to change.
-	</p>
-	</subsection>
-	<subsection name="&sect-num;.5.4 JMeter" anchor="JMeter">
-	<p>
-	If you have non-standard requirements, then this solution offers an
-	open-source community to provide them (of course, if you are reading
-	<u>this</u>, you are probably already committed to this one). This
-	product is free to evolve along with your requirements.
-	</p>
-	</subsection>
+    <subsection name="&sect-num;.5.1 Apache 'ab' tool" anchor="ab">
+    <p>
+    You should definitely start with this one. It handles HTTP 'get' requests
+    very well, and can be made to handle HTTP 'post' requests with a little
+    effort. Written in 'C', it performs very well, and offers good (if basic)
+    performance reporting.
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.5.2 HttpUnit" anchor="httpunit">
+    <p>
+    This is worth a look. It is a library (and therefore of more interest to
+    developers) that can be used to perform HTTP tests/benchmarks. It is
+    intended to be used instead of a web browser (therefore no GUI) in
+    conjunction with <b>JUnit</b>.
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.5.3 Microsoft WAS" anchor="WAS">
+    <p>
+    This is definitely worth a look. It has an excellent user interface
+    but it may not do exactly what you want. If this is the case, be aware
+    that the functionality of this product is not likely to change.
+    </p>
+    </subsection>
+    <subsection name="&sect-num;.5.4 JMeter" anchor="JMeter">
+    <p>
+    If you have non-standard requirements, then this solution offers an
+    open-source community to provide them (of course, if you are reading
+    <u>this</u>, you are probably already committed to this one). This
+    product is free to evolve along with your requirements.
+    </p>
+    </subsection>
 </subsection>
 <subsection name="&sect-num;.6 Why Java ?" anchor="java">
 <p>Why not Perl or C ?

Modified: jmeter/trunk/xdocs/usermanual/build-ldap-test-plan.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/build-ldap-test-plan.xml?rev=1457581&r1=1457580&r2=1457581&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/build-ldap-test-plan.xml (original)
+++ jmeter/trunk/xdocs/usermanual/build-ldap-test-plan.xml Sun Mar 17 22:58:08 2013
@@ -30,7 +30,7 @@
 
 <body>
 <section name="&sect-num;. Building an LDAP Test Plan" anchor="building">
-		<p>In this section, you will learn how to create a basic Test Plan to test an LDAP
server.
+        <p>In this section, you will learn how to create a basic Test Plan to test
an LDAP server.
 You will create four users that send requests for four tests on the LDAP server.Also, you
will tell
 the users to run their tests twice. So,  the total number of requests is (4 users) x (4 requests)
x
 repeat 2 times) = 32 LDAP requests. To construct the Test Plan, you will use the following
elements:
@@ -39,10 +39,10 @@ repeat 2 times) = 32 LDAP requests. To c
 <complink name="LDAP Request Defaults"/>, and
 <complink name="View Results in Table"/>
 .</p>
-		<p>This example assumes that the LDAP Server is installed in your Local machine.</p>
+        <p>This example assumes that the LDAP Server is installed in your Local machine.</p>
 </section>
-	<section name="&sect-num;.1 Adding Users" anchor="adding_users">
-		<p>The first step you want to do with every JMeter Test Plan is to add a Thread Group
element.
+    <section name="&sect-num;.1 Adding Users" anchor="adding_users">
+        <p>The first step you want to do with every JMeter Test Plan is to add a Thread
Group element.
 The Thread Group tells JMeter the number of users you want to simulate, how often the users
should send
 requests, and the how many requests  they should send.</p>
                 <p>Go ahead and add the ThreadGroup element by first selecting the
Test Plan, clicking your
@@ -54,56 +54,56 @@ Figure &sect-num;.1. Thread Group with D
 
 </p>
 </section>
-	<section name="&sect-num;.2 Adding Login Config Element" anchor="add_login">
-		<p>Begin by selecting the Siptech Users element. Click your right mouse
+    <section name="&sect-num;.2 Adding Login Config Element" anchor="add_login">
+        <p>Begin by selecting the Siptech Users element. Click your right mouse
 button to get the Add menu, and then select Add --> Config Element --> Login Config
Element.
 Then,  select this new element to view its Control Panel.</p>
-		<p>Like most JMeter elements, the Login  Config Element  Control Panel has a name
+        <p>Like most JMeter elements, the Login  Config Element  Control Panel has
a name
 field that you can modify. In this example, leave this field with the default value.</p>
 
 <figure image="ldaptest/login-config-element.png">
   Figure &sect-num;.2 Login Config Element for our Test Plan</figure>
 
-		<note><p>Enter Username field to "your Server Username",<br/>
-		The password field to "your Server Passowrd"</p>
+        <note><p>Enter Username field to "your Server Username",<br/>
+        The password field to "your Server Passowrd"</p>
 
-		<p>These values are default for the LDAP Requests.</p></note>
+        <p>These values are default for the LDAP Requests.</p></note>
 </section>
 
-	<section name="&sect-num;.3 Adding LDAP Request Defaults" anchor="add_defaults">
+    <section name="&sect-num;.3 Adding LDAP Request Defaults" anchor="add_defaults">
                 <p>Begin by selecting the Siptech Users element. Click your right mouse
button
 to get the Add menu, and then select Add --> Config Element -->LDAP Request Defaults.
Then,
 select this new element to view its Control Panel.</p>
-		<p>Like most JMeter elements, the LDAP Request Defaults Control Panel has a name
+        <p>Like most JMeter elements, the LDAP Request Defaults Control Panel has a
name
 field that you can modify. In this example, leave this field with the default value.</p>
 
 
 <figure image="ldaptest/requestdefaults.png">
   Figure &sect-num;.3 LDAP Defaults for our Test Plan</figure>
 
-		<note>Enter DN field to "your Server Root Dn".<br/>
+        <note>Enter DN field to "your Server Root Dn".<br/>
                 Enter LDAP Server's Servername field to "localhost".<br/>
-		The port to  389.<br/>
-		These values are default for the LDAP Requests.</note>
+        The port to  389.<br/>
+        These values are default for the LDAP Requests.</note>
 </section>
 
 
-	<section name="&sect-num;.4 Adding LDAP Requests" anchor="add_requests">
+    <section name="&sect-num;.4 Adding LDAP Requests" anchor="add_requests">
                 <p>In our Test Plan, we need to make four LDAP requests.</p>
                 <ol>
-			<li>Inbuilt Add Test</li>
-			<li>Inbuilt Modify Test</li>
-			<li>Inbuilt Delete Test</li>
-			<li>Inbuilt Search Test</li>
-		</ol>
-		<p>JMeter sends requests in the order that you add them to the tree.
+            <li>Inbuilt Add Test</li>
+            <li>Inbuilt Modify Test</li>
+            <li>Inbuilt Delete Test</li>
+            <li>Inbuilt Search Test</li>
+        </ol>
+        <p>JMeter sends requests in the order that you add them to the tree.
 Start by adding the first LDAP Request to the Siptech Users element (Add -->
 Sampler --> LDAP Request). Then, select the LDAP Request  element in the tree
 and edit the following properties</p>
-		<ol>
-			<li>Change the Name to "Inbuilt-Add Test".</li>
-			<li>Select the Add test Radio button</li>
-		</ol>
+        <ol>
+            <li>Change the Name to "Inbuilt-Add Test".</li>
+            <li>Select the Add test Radio button</li>
+        </ol>
                 <figure image="ldaptest/add.png">
                   Figure &sect-num;.4.1 LDAP Request for Inbuilt Add test</figure>
 
@@ -111,35 +111,35 @@ and edit the following properties</p>
                 <p>You do not have to set the Server Name field, port field, Username,
Password
 and DN because you already specified this value in the Login Config Element and
 LDAP Request Defaults.</p>
-		<p>Next, add the second LDAP Request and edit the following
+        <p>Next, add the second LDAP Request and edit the following
 properties</p>
-		<ol>
-			<li>Change the Name to "Inbuilt-Modify Test".</li>
-			<li>Select the Modify test Radio button</li>
-		</ol>
-		Next, add the Third LDAP Request and edit the following properties
+        <ol>
+            <li>Change the Name to "Inbuilt-Modify Test".</li>
+            <li>Select the Modify test Radio button</li>
+        </ol>
+        Next, add the Third LDAP Request and edit the following properties
                 <figure image="ldaptest/modify.png">
                   Figure &sect-num;.4.2 LDAP Request for Inbuilt Modify test</figure>
 
-		<ol>
-			<li>Change the Name to "Inbuilt-Delete Test".</li>
-			<li>Select the Delete test Radio button</li>
-		</ol>
-		Next, add the fourth LDAP Request and edit the following properties
+        <ol>
+            <li>Change the Name to "Inbuilt-Delete Test".</li>
+            <li>Select the Delete test Radio button</li>
+        </ol>
+        Next, add the fourth LDAP Request and edit the following properties
                 
                 <figure image="ldaptest/delete.png">
                   Figure &sect-num;.4.3 LDAP Request for Inbuilt Delete test</figure>
 
                 <ol>
-			<li>Change the Name to "Inbuilt-Search Test".</li>
-			<li>Select the Search test Radio button</li>
-		</ol>
+            <li>Change the Name to "Inbuilt-Search Test".</li>
+            <li>Select the Search test Radio button</li>
+        </ol>
                 <figure image="ldaptest/search.png">
                   Figure &sect-num;.4.4 LDAP Request for Inbuilt Search test</figure>
 
 </section>
-	<section name="&sect-num;.5 Adding a Listener to View/Store the Test Results" anchor="add_listener">
-       		<p>The final element you need to add to your Test Plan is a Listener.
+    <section name="&sect-num;.5 Adding a Listener to View/Store the Test Results"
anchor="add_listener">
+               <p>The final element you need to add to your Test Plan is a Listener.
  This element is responsible for storing all of the results of your LDAP
 requests in a file  and presenting a visual model of the data.Select the Siptech
 Users element and add a View Results in Table (Add --> Listener -->View Results in
Table)</p>

Modified: jmeter/trunk/xdocs/usermanual/build-ldapext-test-plan.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/build-ldapext-test-plan.xml?rev=1457581&r1=1457580&r2=1457581&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/build-ldapext-test-plan.xml (original)
+++ jmeter/trunk/xdocs/usermanual/build-ldapext-test-plan.xml Sun Mar 17 22:58:08 2013
@@ -6,9 +6,9 @@
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at
- 
+
        http://www.apache.org/licenses/LICENSE-2.0
- 
+
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -30,14 +30,14 @@
 <body>
 <section name="&sect-num;. Building an Extended LDAP Test Plan" anchor="ldapexttest">
 <p>
-In this section, you will learn how to create a basic Test Plan to test an LDAP 
+In this section, you will learn how to create a basic Test Plan to test an LDAP
 server.</p>
 <p>
-As the Extended LDAP Sampler is highly configurable, this also means that it takes 
-some time to build a correct testplan. You can however tune it exactly up to your 
+As the Extended LDAP Sampler is highly configurable, this also means that it takes
+some time to build a correct testplan. You can however tune it exactly up to your
 needs.
 </p>
-	
+
 <p>
 You will create four users that send requests for four tests on the LDAP server.Also, you
will tell
 the users to run their tests twice. So,  the total number of requests is (4 users) x (4 requests)
x
@@ -51,14 +51,14 @@ repeat 2 times) = 32 LDAP requests. To c
 This example assumes that the LDAP Server is installed in your Local machine.
 </p>
 <p>
-For the less experienced LDAP users, I build a <a href="ldapops_tutor.html">small 
-LDAP tutorial</a> which shortly explains 
+For the less experienced LDAP users, I build a <a href="ldapops_tutor.html">small
+LDAP tutorial</a> which shortly explains
 the several LDAP operations that can be used in building a complex testplan.
 </p>
 <p>
-Take care when using LDAP special characters in the distinghuished name, in that case (eg,
you want to use a + sign in a 
+Take care when using LDAP special characters in the distinghuished name, in that case (eg,
you want to use a + sign in a
 distinghuished name) you need to escape the character by adding an "\" sign before that character.
-extra exeption: if you want to add a \ character in a distinguished name (in an add or rename
operation), you need to use 4 backslashes. 
+extra exeption: if you want to add a \ character in a distinguished name (in an add or rename
operation), you need to use 4 backslashes.
 examples:
 cn=dolf\+smits to add/search an entry with the name like cn=dolf+smits
 cn=dolf \\ smits to search an entry with the name cn=dolf \ smits
@@ -66,7 +66,7 @@ cn=c:\\\\log.txt to add an entry with a 
 </p>
 
 
-	<subsection name="&sect-num;.1 Adding Users" anchor="ext_adding_users">
+    <subsection name="&sect-num;.1 Adding Users" anchor="ext_adding_users">
 <p>
 The first step you want to do with every JMeter Test Plan is to add a Thread Group element.
 The Thread Group tells JMeter the number of users you want to simulate, how often the users
should send
@@ -84,7 +84,7 @@ Figure &sect-num;.1. Thread Group with D
 
 </p>
 </subsection>
-	<subsection name="&sect-num;.2 Adding LDAP Extended Request Defaults" anchor="add_ldapext_defaults">
+    <subsection name="&sect-num;.2 Adding LDAP Extended Request Defaults" anchor="add_ldapext_defaults">
 <p>
 Begin by selecting the Thread Group element. Click your right mouse button
 to get the Add menu, and then select Add --> Config Element -->LDAP Extended Request
Defaults. Then,
@@ -94,16 +94,16 @@ select this new element to view its Cont
 Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name
 field that you can modify. In this example, leave this field with the default value.
 </p>
-<p><figure image="ldaptest/extrequestdefaults.png"><br/>						
+<p><figure image="ldaptest/extrequestdefaults.png"><br/>
   Figure &sect-num;.2 LDAP Defaults for our Test Plan</figure>
 </p>
 <p>
-			For each of the different operations, some default values can be filled in.
-			In All cases, when a default is filled in, this is used for the LDAP extended requests.
-			For each requst, you can override the defaults by filling in the values in the LDAP extended
request sampler.
-			When no valueis entered which is necesarry for a test, the test will fail in an unpredictable
way!
-			</p>
-			We will not enter any default values here, as we will build a very small testplan, so
we will explain all the different fields when we add the LDAP Extended samplers.
+            For each of the different operations, some default values can be filled in.
+            In All cases, when a default is filled in, this is used for the LDAP extended
requests.
+            For each requst, you can override the defaults by filling in the values in the
LDAP extended request sampler.
+            When no valueis entered which is necesarry for a test, the test will fail in
an unpredictable way!
+            </p>
+            We will not enter any default values here, as we will build a very small testplan,
so we will explain all the different fields when we add the LDAP Extended samplers.
 </subsection>
 <subsection name="&sect-num;.3 Adding LDAP Requests" anchor="add_extrequests">
 <p>
@@ -178,7 +178,7 @@ When this field is kept empty, an anonym
 <p>
 <figure image="ldaptest/extthreadbind.png">
 Figure &sect-num;.3.1. Thread Bind example</figure>
-</p> 
+</p>
 </subsection>
 
 <subsection name="&sect-num;.3.2 Adding a search Request" anchor="add_searchreq">
@@ -205,7 +205,7 @@ Enter the searchfilter, any decent LDAP 
      </li></ol>
 </li>
 <li>
-(Optional) Sizelimit, specifies the maximun number of returned entries, 
+(Optional) Sizelimit, specifies the maximun number of returned entries,
 </li>
 <li>
 (optional) Timelimit, psecifies the maximum number of miliseconds, the SERVER can use for
performing the search. it is NOT the maximun time the application will wait!<br/>
@@ -420,7 +420,7 @@ The request gives a short description of
 is contained here.
 </li>
 <li>
-The response data contains the full details of the sent request, as well the full details
of the received answer, 
+The response data contains the full details of the sent request, as well the full details
of the received answer,
 this is given in a (self defined) xml-style.
 <a href="ldapanswer_xml.html">The full description can be found here.</a>
 </li>



Mime
View raw message