flightPATH是ADC内置的流量管理技术。flightPATH允许你实时检查HTTP和HTTPS流量，并根据条件执行行动。
在规则中使用IP对象时，flightPATH规则必须应用于VIP。
一个飞行路径规则由四个要素组成。
1. 详细信息，在这里你可以定义flightPATH名称和它所连接的服务。
2. 可以定义的导致规则被触发的条件。
3. 评价，允许定义可在行动中使用的变量。
4. 用于管理满足条件时应发生的事情的行动
详细内容
细节部分显示了可用的flightPATH规则。你可以在这部分添加新的flightPATH规则和删除已定义的规则。
添加一个新的flightPATH规则
|
场地
|
描述
|
|
飞行路线名称
|
这个字段是为flightPATH规则命名的。你在这里提供的名称会出现在ADC的其他部分并被引用。
|
|
适用于VS
|
这一栏是只读的，显示应用flightPATH规则的VIP。
|
|
描述
|
代表为可读性而提供的描述的值。
|
添加flightPATH规则的步骤
1. 首先，点击位于细节部分的添加新按钮。
2. 为你的规则输入一个名称。例子 Auth2
3. 输入对你的规则的描述
4. 一旦规则被应用到一个服务上，你会看到应用到一栏自动填充了一个IP地址和端口值
5. 不要忘记点击 "更新 "按钮来保存你的变化，如果你犯了一个错误，只需点击 "取消 "即可恢复到以前的状态。
状况
一个flightPATH规则可以有任何数量的条件。这些条件在AND的基础上工作，允许你设置触发行动的条件。如果你想使用OR条件，创建一个额外的flightPATH规则，并以正确的顺序将其应用于VIP。
你也可以通过在Check字段选择Match RegEx，在Value字段选择RegEx值来使用RegEx。RegEx评估的加入极大地扩展了flightPATH的能力。
创建一个新的flightPATH条件
状况
我们在下拉菜单中提供了几个预定义的条件，涵盖了所有可预见的情况。当新的条件被添加时，这些条件将通过Jetpack的更新来提供。
可供选择的是。
|
状况
|
描述
|
例子
|
|
<表格>
|
HTML表格是用来向服务器传递数据的
|
例子 "表格没有长度0"
|
|
GEO位置
|
将源IP地址与ISO 3166国家代码相比较
|
GEO位置等于GB，或GEO位置等于德国
|
|
宿主
|
从URL中提取的主机
|
www.mywebsite.com 或 192.168.1.1
|
|
语言
|
从HTTP头的语言中提取的语言
|
这个条件将产生一个带有语言列表的下拉菜单
|
|
方法
|
HTTP方法的下拉菜单
|
包括GET、POST等的下拉菜单
|
|
原产地IP
|
如果上游代理支持X-Forwarded-for（XFF），它将使用真正的Origin地址。
|
客户端IP。它也可以使用多个IP或子网。
10.1\.2.*是10.1.2.0 /24子网
10.1\.2.3|10.1\.2.4使用|为多个IP的。
|
|
路径
|
网站的路径
|
/mywebsite/index.asp
|
|
帖文
|
POST请求方法
|
检查正在上传到网站的数据
|
|
查询
|
查询的名称和值，可以接受查询名称，也可以接受一个值
|
"Best=jetNEXUS"，其中匹配的是Best，值是edgeNEXUS。
|
|
查询字符串
|
在? 字符之后的整个查询字符串
|
|
|
索取饼干
|
客户端要求的一个cookie的名称
|
MS-WSMAN=afYfn1CDqqCDqUD::
|
|
请求标题
|
任何HTTP标头
|
Referrer, User-Agent, From, Date
|
|
要求版本
|
HTTP版本
|
http/1.0或http/1.1
|
|
回应机构
|
响应体中的一个用户定义的字符串
|
服务器升级
|
|
响应代码
|
响应的HTTP代码
|
200 OK, 304 Not Modified
|
|
回应饼干
|
服务器发送的一个cookie的名称
|
MS-WSMAN=afYfn1CDqqCDqUD::
|
|
响应头
|
任何HTTP标头
|
Referrer, User-Agent, From, Date
|
|
回复版本
|
服务器发送的HTTP版本
|
http/1.0或http/1.1
|
|
来源于IP
|
起源IP，代理服务器IP，或其他一些聚合的IP地址
|
客户端
IP、代理IP、防火墙IP。也可以使用多个IP和子网。你必须转义点，因为这些是RegEX。例如10\.1\.2\.3是10.1.2.3
|
匹配
匹配字段可以是下拉式或文本值，可根据条件字段的值来定义。例如，如果Condition被设置为Host，Match字段就不可用。如果条件设置为<form>，则匹配字段显示为文本字段，如果条件为POST，则匹配字段显示为一个包含相关值的下拉式。
可供选择的是。
|
匹配
|
描述
|
例子
|
|
接受
|
可接受的内容类型
|
接受: text/plain
|
|
接受-编码
|
可接受的编码
|
Accept-Encoding: <compress | gzip | deflate | sdch | identity >。
|
|
接受语言
|
可接受的回应语言
|
Accept-Language: en-US
|
|
接受范围
|
该服务器支持哪些部分内容范围类型
|
接受-范围: bytes
|
|
授权书
|
用于HTTP认证的认证凭证
|
授权。Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
|
收费-目的
|
包含应用所申请方法的费用的账户信息
|
|
|
内容-编码
|
使用的编码类型
|
Content-Encoding: gzip
|
|
内容-长度
|
响应体的长度，单位是八位数（8位字节）。
|
内容-长度: 348
|
|
内容-类型
|
请求正文的mime类型（用于POST和PUT请求）。
|
Content-Type: application/x-www-form-urlencoded
|
|
饼干
|
服务器之前用Set-Cookie发送的一个HTTP cookie（如下）。
|
Cookie: $Version=1; Skin=new;
|
|
日期
|
信息发出的日期和时间
|
Date = "Date" ":" HTTP-date
|
|
ETag
|
一个资源的特定版本的标识符，通常是一个消息摘要
|
ETag。"aed6bdb8e090cd1:0"
|
|
来自
|
提出请求的用户的电子邮件地址
|
来自: user@example.com
|
|
如果修改过-自
|
如果内容没有变化，允许返回304未修改。
|
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
|
最后修改时间
|
请求对象的最后修改日期，格式为RFC 2822
|
最后修改的。Tue, 15 Nov 1994 12:45:26 GMT
|
|
プラグマ
|
实施。具体的标头，在请求-响应链的任何地方都可能产生各种影响。
|
Pragma: no-cache
|
|
推荐人
|
前一个网页的地址，从该网页链接到当前请求的页面。
|
推荐人: HTTP://www.edgenexus.io
|
|
服务器
|
服务器的一个名称
|
服务器。Apache/2.4.1 (Unix)
|
|
设置参数
|
一个HTTP cookie
|
Set-Cookie:UserID=JohnDoe; Max-Age=3600; Version=1
|
|
用户代理
|
用户代理的用户代理字符串
|
用户代理。Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
|
|
不尽相同
|
告诉下游代理如何匹配未来的请求头，以决定
是否可以使用缓存的响应，而不是
从源服务器
请求一个新的响应。
|
变化。用户代理
|
|
X-Powered-By
|
指定支持网络应用的技术（如ASP.NET、PHP、JBoss）。
|
X-Powered-By:PHP/5.4.0
|
感知
意义字段是一个下拉布尔字段，包含有 "有 "或 "无 "的选择。
检查
检查字段允许设置针对条件的检查值。
可用的选择是。包含, 结束, 平等, 存在, 有长度, 匹配RegEx, 匹配列表, 开始, 超过长度
|
检查
|
描述
|
例子
|
|
存在的
|
这不关心条件的细节，只关心它的存在/不存在。
|
宿主 - 确实 - 存在
|
|
开始
|
该字符串以 "值 "开始
|
路径 - Does - Start - /secure
|
|
结束
|
字符串以 "值 "结束。
|
Path - Does - End - .jpg
|
|
包含
|
该字符串确实包含了价值
|
请求头 - 接受 - 是否 - 包含 - 图像
|
|
平等
|
字符串确实等于值
|
主持人 - 是否 - 平等 - www.edgenexus.io
|
|
有长度
|
该字符串确实有一个长度的值
|
主机 - 是否 - 有长度 - 16
www.edgenexus.io = TRUE
www.edgenexus.com = FALSE
|
|
匹配RegEx
|
使你能够输入一个完整的与Perl兼容的正则表达式
|
起始IP - 是否 - 匹配Regex - 10\.* | 11\.*
|
添加一个条件的步骤
添加一个新的flightPATH条件是非常容易的。上面是一个例子。
1. 点击条件区域内的添加新按钮。
2. 从下拉框中选择一个条件。让我们以主机为例。你也可以在该字段中输入，ADC会在下拉框中显示该值。
3. 选择一种感觉。例如，是否
4. 选择一个检查。例如，包含
5. 选择一个值。例如，mycompany.com
上面的例子表明，有两个条件必须都是 "真"，才能完成规则
· 首先是检查所请求的对象是否是一个图像
· 第二个检查URL中的主机是否为www.imagepool.com
评价
添加可定义变量的能力是一种引人注目的能力。普通的ADC使用脚本或命令行选项来提供这种能力，这对任何人来说都不理想。ADC允许你使用一个易于使用的GUI来定义任何数量的变量，如下所示和描述。
flightPATH变量的定义包括四个需要做的条目。
· 变量 - 这是变量的名称
· 来源 - 可能的来源点的下拉列表
· 细节--从下拉菜单中选择数值或手动输入。
· Value - 变量持有的值，可以是一个字母数字值或用于微调的RegEx。
内置变量。
内置变量已经被硬编码了，所以你不需要为这些变量创建一个评估条目。
你可以在行动部分使用下面列出的任何变量。
每个变量的解释都在上面的 "条件 "表中。
· 方法=$method$
· 路径 = $path$
· Querystring = $querystring$
· Sourceip = $sourceip$
· 响应代码（文本也包括 "200 OK"）= $resp$
· 主机=$host$
· 版本 = $version$
· 客户端口 = $clientport$
· Clientip = $clientip$
· 地理定位=$geolocation$"
|
行动
|
目标
|
|
行动 = 重定向 302
|
目标 = HTTPs://$host$/404.html
|
|
行动=记录
|
目标 = 一个来自$sourceip$:$sourceport$的客户刚刚提出了一个$path$页面请求
|
解释一下。
· 客户在访问不存在的页面时，通常会看到浏览器的404错误页面。
· 相反，用户被重定向到他们使用的原始主机名，但错误的路径被替换为404.html
· 一个条目被添加到Syslog中说："一个来自154.3.22.14:3454的客户刚刚请求了错误的.html页面"。
行动
这个过程的下一个阶段是添加一个与flightPATH规则和条件相关的行动。
在这个例子中，我们要重写URL的路径部分，以反映用户输入的URL。
· 点击添加新的
· 从行动下拉菜单中选择重写路径
· 在目标字段中，键入$path$/myimages
· 点击更新
这个动作将在路径中加入/myimages，所以最终的URL变成了www.imagepool.com/myimages
应用flightPATH规则
任何flightPATH规则的应用都是在每个VIP/VS的flightPATH标签中进行的。
· 导航到服务 > IP服务，并选择你想分配flightPATH规则的VIP。
· 你将看到如下所示的真实服务器列表
· 点击flightPATH标签
· 选择你已经配置的flightPATH规则或支持的预建规则之一。如果需要，你可以选择多个flightPATH规则。
· 将所选的集子拖放到Applied flightPATHs部分或点击>>箭头按钮。
· 该规则将被移至右侧并自动应用。
