-
Getting Started with Citrix NetScaler
-
Deploy a Citrix NetScaler VPX instance
-
Install a Citrix NetScaler VPX instance on Microsoft Hyper-V servers
-
Install a NetScaler VPX instance on Linux-KVM platform
-
Prerequisites for Installing NetScaler VPX Virtual Appliances on Linux-KVM Platform
-
Provisioning the NetScaler Virtual Appliance by using OpenStack
-
Provisioning the NetScaler Virtual Appliance by using the Virtual Machine Manager
-
Configuring NetScaler Virtual Appliances to Use SR-IOV Network Interface
-
Configuring NetScaler Virtual Appliances to use PCI Passthrough Network Interface
-
Provisioning the NetScaler Virtual Appliance by using the virsh Program
-
-
Deploying NetScaler VPX Instances on AWS
-
Upgrade and downgrade a NetScaler appliance
-
-
-
-
-
-
Overriding Static Proximity Behavior by Configuring Preferred Locations
-
Example of a Complete Parent-Child Configuration Using the Metrics Exchange Protocol
-
Configuring Global Server Load Balancing for DNS Queries with NAPTR records
-
Using the EDNS0 Client Subnet Option for Global Server Load Balancing
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Use source IP address of the client when connecting to the server
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
-
-
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a NetScaler Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已动态机器翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.
Este artigo foi traduzido automaticamente.
这篇文章已经过机器翻译.放弃
Translation failed!
Web services interoperability check
The Web Services Interoperability (WS-I) check examines both requests and responses for adherence to the WS-I standard, and blocks those requests and responses that do not adhere to this standard. The purpose of the WS-I check is to block requests that might not interact with other XML appropriately. An attacker can use inconsistencies in interoperability to launch an attack on your XML application.
If you use the wizard or the GUI, in the Modify Web Services Interoperability Check dialog box, on the General tab you can enable or disable the Block, Log, Statistics, and Learn actions.
If you use the command-line interface, you can enter the following command to configure the Web Services Interoperability check:
set appfw profile <name> -xmlWSIAction [block] ][log] [learn] [stats] [none]
To configure individual Web Services Interoperability rules, you must use the GUI. On the Checks tab of the Modify Web Services Interoperability Check dialog box, select a rule and click Enable or Disable to enable or disable the rule. You can also click Open to open the Web Services Interoperability Detail message box for that rule. The message box displays read-only information about the rule. You cannot modify or make other configuration changes to any of these rules.
The WS-I check uses the rules listed in WS-I Basic Profile 1.0. WS-I delivers best practices for developing interoperable Web Services solutions. WS-I checks are performed only on SOAP Messages.
Description of each WSI standard rule is provided below:
Rule | Description |
---|---|
BP1201 | Message body should be a soap:envelope with namespace. |
R1000 | When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have element children other than faultcode, faultstring, faultactor and detail. |
R1001 | When an ENVELOPE is a Fault, the element children of the soap:Fault element MUST be unqualified. |
R1003 | A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than the namespace of the qualified document element Envelope. |
R1004 | When an ENVELOPE contains a faultcode element, the content of that element SHOULD be either one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element), or a Qname whose namespace is controlled by the fault’s specifying authority (in that order of preference). |
R1005 | An ENVELOPE MUST NOT contain soap:encodingStyle attribute on any of the elements whose namespace is the same as the namespace of the qualified document element Envelope. |
R1006 | An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body. |
R1007 | An ENVELOPE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any element that is a grandchild of soap:Body. |
R1011 | An ENVELOPE MUST NOT have any element children of soap:Envelope following the soap:Body element. |
R1012 | A MESSAGE MUST be serialized as either UTF-8 or UTF-16. |
R1013 | An ENVELOPE containing a soap:mustUnderstand attribute MUST only use the lexical forms 0 and 1. |
R1014 | The children of the soap:Body element in an ENVELOPE MUST be namespace qualified. |
R1015 | A RECEIVER MUST generate a fault if they encounter an envelope whose document element is not soap:Envelope. |
R1031 | When an ENVELOPE contains a faultcode element the content of that element SHOULD NOT use of the SOAP 1.1 dot notation to refine the meaning of the fault. |
R1032 | The soap:Envelope, soap:Header, and soap:Body elements in an ENVELOPE MUST NOT have attributes in the same namespace as that of the qualified document element Envelope |
R1033 | An ENVELOPE SHOULD NOT contain the namespace declaration: xmlns:xml=http://www.w3.org/XML/1998/namespace.
|
R1109 | The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string. |
R1111 | An INSTANCE SHOULD use a 200 OK HTTP status code on a response message that contains an envelope that is not a fault. |
R1126 | An INSTANCE MUST return a 500 Internal Server Error HTTP status code if the response envelope is a Fault. |
R1132 | A HTTP request MESSAGE MUST use the HTTP POST method. |
R1140 | A MESSAGE SHOULD be sent using HTTP/1.1. |
R1141 | A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0. |
R2113 | An ENVELOPE MUST NOT include the soapenc:arrayType attribute. |
R2211 | An ENVELOPE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of 1 or true on the part accessors. |
R2714 | For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains an envelope. Specifically, the HTTP response entity-body must be empty. |
R2729 | An ENVELOPE described with an rpc-literal binding that is a response MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the stringResponse. |
R2735 | An ENVELOPE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace. |
R2738 | An ENVELOPE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it. |
R2740 | A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:fault describing each known fault. |
R2744 | A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description. |
Share
Share
In this article
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.