用于处理超文本传输协议请求的方法和系统的制作方法

专利名称：用于处理超文本传输协议请求的方法和系统的制作方法
技术领域：
本发明涉及超文本传输协议(HTTP，Hypertext Transfer Protocol)会话技术，尤 其涉及用于处理HTTP请求的方法和系统。
背景技术：
HTTP超文本传输协议是一种单向协议。所谓单向协议是指，根据HTTP协议，服务 器不能主动向客户端发出连接请求，只能被动地等待并答复客户端发出的HTTP请求。由于 HTTP其本身并不支持在服务器保存客户端的状态信息，因此引入了一种状态管理机制，即 会话机制，用以在服务器与客户端之间保持会话状态。会话机制的引入克服了 HTTP的一些限制，使得能够在客户端及服务器维护各 HTTP请求间的关系。根据会话机制，当客户端初次连接服务器时，在服务器建立HTTP会话 并保存与该会话相关的变量，同时产生一个HTTP会话标识(session id)用来识别该会话 的变量。接着，服务器会在HTTP响应中指示浏览器在客户端生成与该HTTP会话标识对应 的“Cookie”。Cookie是服务器存储在客户端的一小段文本，在会话期间，每次通过浏览器 向服务器发出HTTP请求时，都会将Cookie中包含的会话标识包括在HTTP请求中发送给服 务器，从而使服务器能够识别该会话，并获得与该会话相关的变量。然而，在现有技术中，通常存在这样的情况，S卩，通常在一个HTTP会话中需要运行 与同一应用对应的多个应用实例。由于同一应用多个应用实例的域名都是相同的，在这种 情况下，应用的服务器为请求访问不同的应用实例的所有HTTP请求均生成相同的会话标 识(sessionid)，也就是说，该多个应用实例共享了同一个HTTP会话。此时，就可能会出现 问题，例如数据混淆、数据丢失、数据出错等，并且严重影响用户体验。图1示出了传统的、可能会出现问题的具有多个应用实例的应用环境的示例。如 图1所示，在该示例中，有两个服务器，一个是门户服务器110，另一个是软件即服务应用 (SaaS, Software As a Service)服务器，诸如结算服务器120。用户可以通过浏览器以自己的用户名和密码登陆门户服务器110，随后用户进入 页面100。在页面100中，包括有三个用户接口组件，即内嵌框架(IFrame)101、内嵌框架 102和内嵌框架103。IFramelOUIFrame 102和IFrame 103都对应于相同的结算应用，因 此它们的接入点(IP地址)相同。然而，与IFrame 101对应的服务实例是“A”公司的主数 据，与IFrame 102对应的服务实例是“B”公司的主数据，而与IFrame 103对应的服务实例 是与“C”公司对应的主数据。在图1的左下方示出了这三个IFrame都打开时的Cookie 104的示例。从该 示例可以看出，Cookie 104中存在两个会话标识，即SESSIONID 105和SESSIONID 106。 SESSIONID 105用于在与门户服务器110通信时使用，同时在门户服务器110中保存有与 SESSI0NID105对应的变量信息111。SESSIONID 106用于在与结算服务器120通信时使用， 同时在结算服务器120中保存有与SESSIONID 106对应的变量信息121。根据现有技术，尽管在这种情况下存在与结算应用对应的三个应用实例，但在与结算服务器120通信时，却都是使用SEESI0NID 106，这是因为应用服务器(结算服务器) 对于请求访问这三个应用实例的HTTP请求只分配一个HTTP会话标识(session id)—— SESSI0NID106。由于利用该SESSI0NID 106根本无法区分正在使用的是哪个应用实例，因 此通常会出现问题。这是因为在对“A”公司的主数据进行操作之后，结算服务器120处所 存储的会话变量是与“A”公司相关的值，而在对“B”公司的主数据进行操作后，结算服务器 120处所存储的会话变量可能是与“B”公司相关的值。因此，在操作了 “B”公司的主数据 后，再提交访问“A”公司的HTTP请求以返回查看“A”公司的主数据，此时看到的实际可能 是与“B”公司相关的主数据。这造成了极大的混乱，并且还会出现数据错误的问题。为了解决该问题，在一些应用中，特别地设计了一种机制，该机制在检测到在同一 HTTP会话期间要求实例化同一应用的多个服务实例时，禁止该操作。换句话讲，如果想要处 理其他公司的数据，必须结束当前HTTP会话，重新连接服务器。利用这种方式，虽然避免了 数据混乱和数据错误的问题，但是却非常麻烦，给用户带来了很不好的体验。因此，这种解 决方案在根本上是不能满足商业需求的。还有另一种解决方案，即仅确保最后接入的服务实例的数据正确。这种方案简单， 但是用户不能查看先前应用实例的主数据。这依然给用户带来了很大的不便。虽然图1示出了结算服务器和门户服务器位于同一域中的环境，实际上在结算服 务器和门户服务器处于不同域时也同样会存在这些问题。

发明内容
为此，本发明提供了一种用于处理HTTP请求的方法和系统，以便克服现有技术中 的问题。根据本发明的一个方面，提供了一种用于处理超文本传输协议HTTP请求的方法， 包括接收要对应用的实例进行访问的原始HTTP请求；如果所述原始HTTP请求要访问的 域名与所述应用的域名相同，将所述原始HTTP请求要访问的域名修改为与所述应用的域 名不同的新域名，以生成要对所述应用的实例进行访问的新的HTTP请求，并且将所述新的 HTTP请求发送至所述应用的服务器以对所述应用的实例进行访问，其中所述原始HTTP请 求要访问的域名和所述新域名对应于相同的IP地址。在本发明的一个实施方式中，所述用于处理超文本传输协议HTTP请求的方法还 包括如果所述原始HTTP请求要访问的域名与所述应用的域名不同，直接将所述原始HTTP 请求发送至所述应用的服务器以对所述应用的实例进行访问。根据本发明的另一方面，提供了一种用于处理超文本传输协议HTTP请求的系统， 包括接收模块，用于接收要对应用的实例进行访问的原始HTTP请求；修改模块，被配置为 如果所述原始HTTP请求要访问的域名与所述应用的域名相同，将所述原始HTTP请求要访 问的域名修改为与所述应用的域名不同的新域名，以生成要对所述应用的实例进行访问的 新的HTTP请求；以及发送模块，被配置为将所述新的HTTP请求发送至所述应用的服务器以 对所述应用的实例进行访问，其中所述原始HTTP请求要访问的域名和所述新域名对应于 相同的IP地址。在本发明的一个实施方式中，所述发送模块还被配置为如果所述原始HTTP请求 要访问的域名与所述应用的域名不同，直接将所述原始HTTP请求发送至所述应用的服务器以对所述应用的实例进行访问。通过本发明的方法和系统，可以避免现有技术中在同一超文本传输协议会话中运 行同一应用的多个服务实例时出现的诸如数据混淆、数据错误、使用不便等各种问题，并给 用户带来了良好的体验，从而很好地满足了商业需求。


通过对结合附图所示出的实施方式进行详细说明，本发明的上述以及其他特征将 更加明显，本发明附图中相同的标号表示相同或相似的部件。在附图中，图1示出了传统的、可能会出现问题的具有多个应用实例的应用环境的示例；图2示意性地示出了根据本发明一个实施方式的用于处理HTTP请求的方法的流 程图；图3示意性地示出了根据本发明另一实施方式的用于处理HTTP请求的方法的流 程图；图4A示意性地示出了根据本发明一个实施方式的对域名进行判断的方法的流程 图；图4B示意性地示出了根据本发明另一实施方式的对域名进行判断的方法的流程 图；图5示意性地示出了根据本发明一个实施方式的用于处理客户端所提交的HTTP 请求的方法的流程图；图6示意性地示出了根据本发明一个实施方式的记录与新域名相关信息的表；图7示意性地示出了根据本发明一个实施方式的用于处理HTTP请求的系统的框 图；图8示意性地示出了根据本发明另一实施方式的用于处理HTTP请求的系统的框 图；图9示意性地示出了根据本发明另一实施方式的用于处理客户端所提交的HTTP 请求的方法的流程图。
具体实施例方式在下文中，将参考附图通过实施方式对本发明提供的用于处理HTTP请求的方法 和系统进行详细地描述。图2示出了根据本发明一个实施方式的用于处理HTTP请求的方法的流程图。参 考图2，首先在步骤201，接收要对应用的实例进行访问的原始HTTP请求，这样的HTTP请求 可以由使用该应用的客户从客户端浏览器发出，之所以称其为原始HTTP请求，是因为这样 的HTTP请求直接由客户端发出并在步骤201中被接收，中间没有经过修改处理。在步骤202中，如果所接收的原始HTTP请求要访问的域名与应用的域名相同，则 将所接收到的原始HTTP请求的域名修改为新域名。从上文对图1的描述中可以看出，对 于一个应用而言，无论它具有多少实例，所有实例的域名都是相同的，也就是说，客户端无 论访问应用的哪一个实例，所提交的HTTP请求中的域名部分都是应用的域名。而在步骤 202中，所修改的新域名显然是指不同于该应用的域名的域名，而且这样的新域名一定与该应用的域名指向相同的IP地址，如果它们不指向相同的IP地址，则客户端显然无法正确 地访问其所要访问的应用。因此，当将原始HTTP请求要访问的域名修改为新域名后，该原 始HTTP请求也就成为了要对所述应用的实例进行访问的新的HTTP请求。本领域技术人 员可以了解，两个或者多个不同的域名指向相同的IP地址属于“泛域名”技术。举例而言， 比如用户的域名是abc. com，那么将主机名设置为“*”，IP解析到比如218. 104.78. 100， 本领域技术人员应当了解“*”是通配符，它表明abc. com之前的所有子域名都将解析到 218. 104. 78. 100，这就意味着例如输入 bbs. abc. com 或者 123. abc. com 或者 123. 234. abc. com 都将解析到 218. 104. 78. 100。根据本发明另一个实施方式，通过向接收到的原始HTTP请求的URL地址的头部加 入随机产生的符号来将原始HTTP请求要访问的域名修改为新的域名。例如，某应用的URL 地址是HTTP: //oa. wds. com,现在客户端请求访问该应用对于公司A的实例a，在用户通过 客户端浏览器点击公司A之后即向应用的服务器发出原始HTTP请求HTTP://oa. wds. com/ oa ？ sid = a,这也就是该原始HTTP请求要访问的URL地址。其中该原始HTTP请求要访 问的域名是oa. wds. com( “/”之前的部分)，那么现在向该域名的头部插入随机产生的符 号“aabbcc”，使得经修改后的新域名变成aabbcc. oa. wds. com。由上述“泛域名”的概念可 知，aabbcc. oa. wds. com和oa. wds. com 一定都将解析到相同的IP地址。应当了解，这只是 其中一种将原始HTTP请求要访问的域名修改为新域名的方式，本领域技术人员可以采取 多种其它方式修改原始HTTP请求要访问的域名，只要保证修改后的新的域名和原始HTTP 请求要访问的域名指向相同的IP地址，即可实现本发明的目的并落入本发明的保护范围。根据本发明的又一个实施方式，上述随机产生的符号应当受到一定的新域名模式 的限制。举例而言，将新域名模式预先定义为“aa****”，也就是说，向域名的头部插入的符 号由6位组成，其中前两位是固定的“aa”，而后4位才是随机产生的其它符号。在预先定义 了这样的新域名模式后，在修改原始HTTP请求要访问的域名时，就按照所定义的新域名模 式进行修改。这样做的其中一个目的是，可以将接收到的原始HTTP请求的域名的模式与预 先定义的新域名模式进行比对，从而判断原始HTTP请求要访问的域名是否与应用的域名 相同。关于这部分内容，在对附图4B的文字描述中有详细记载。还需要指出的是，在一个应用包含多个应用实例的情形下，为了对每个应用实例 的HTTP会话进行隔离，需要对访问每个应用实例的HTTP请求分配不同的HTTP会话标识 (session id)，也就是说，需要将访问每个应用实例的HTTP请求(初次访问该应用实例 时)修改为不同的新的HTTP请求，只有这样，才能保证应用的服务器为访问每个应用实例 的HTTP请求分配不同的HTTP会话标识。在步骤203中，将包含新域名的要对所述应用的实例进行访问的新的HTTP请求发 送至应用的服务器，以对所述应用的实例进行访问。本领域技术人员应当了解，由于应用的 服务器分配HTTP session (会话)是根据所接收到的HTTP请求中的域名部分来进行的，也 就是说对于具有相同的域名部分的HTTP请求分配相同的HTTP会话标识(session id)，而 对于具有不同的域名部分的HTTP请求分配不同的HTTP会话标识(session id)，因此经步 骤202修改后的包含新域名的HTTP请求自然而然地就可以由应用的服务器分配不同于原 始HTTP请求的HTTP会话标识，从而如果对每一个针对同一应用的不同应用实例所提交的 原始HTTP请求都进行这样的修改，就可以使得虽然这些原始HTTP请求要访问的域名部分都相同，但是每一个原始HTTP请求最终都可以由应用的服务器分配不同的HTTP会话标识， 从而对HTTP会话进行隔离。图3根据本发明另一实施方式的用于处理HTTP请求的方法的流程图。可以理解， 图3是在图2的基础上包含了判断步骤以及与客户端交互步骤的流程图。具体地，步骤301 与步骤201相同，接收要对应用的实例进行访问的原始HTTP请求。在步骤302中，对接收到的原始HTTP请求进行判断，判断该请求的域名部分是否 与应用的域名相同。如果判断结果为是，则执行步骤303，如果判断结果为否，则执行步骤 307。在步骤303中，执行与步骤202中相同的操作，将原始HTTP请求的域名修改为新 域名。在步骤304中，将包含修改后的新域名的新HTTP请求返回至客户端，使得客户端能 够记录对应于应用的特定实例的新域名。可选地，客户端可以重新提交所述包含了修改后 的新域名的新的HTTP请求。可选地，客户端仅仅记录对应于应用的特定实例的新域名，但 是并不重新提交所述包含了修改后的新域名的新的HTTP请求。需要指出的是，这里利用了 URL地址重定向技术(URLRedirection)，客户端会自动提交所述新的HTTP请求，也就是包 含被重定向后的URL地址的HTTP请求，而无需用户在客户端再次执行提交HTTP请求的操 作。在这里，将新HTTP请求返回至客户端而不是直接发送至应用的目的在于，使得客户端 知晓并记录其所提交的原始HTTP请求被修改为什么样的新的HTTP请求，这样用户在下一 次请求访问同一应用实例时就可以直接提交被记录下的包含新域名的新HTTP请求，从而 不用再次经历修改域名的过程，也就是在步骤302中判断为否，然后直接执行步骤307将原 始HTTP请求发送至所述应用。需要指出的是，将新的HTTP请求返回至客户端并非本发明 必须的步骤，本领域技术人员也可以选择直接将新的HTTP请求发送至应用，并且在下一次 客户端提交访问同一实例的HTTP请求时重新对原始HTTP请求的域名进行修改。在步骤305中接收由客户端记录完成后并且重新提交的新的HTTP请求，在步骤 306中将新的HTTP请求发送至应用。需要指出的是，步骤305仅是本发明的一种实施方式， 可选地，客户端仅仅记录对应于应用的特定实例的新域名，但是并不重新提交所述包含了 修改后的新域名的新的HTTP请求。图4A和图4B针对图3中的步骤302，进一步给出了两种根据本发明判断原始HTTP 请求的域名是否与应用的域名相同的实施例。如图4a所示，在步骤401A中，获取HTTP请 求要访问的URL地址。本领域技术人员应当了解，在一个完整的HTTP请求中，除了该HTTP 请求要访问的URL地址外，还包括其它的一些信息例如cookie信息。而在步骤401A中仅 需要获取HTTP请求要访问的URL地址，从而在步骤402中分析所获取的URL地址的域名部 分。在步骤403A中，判断所获取的URL地址的域名部分是否与应用域名列表中的域名 相同，如果是，则在步骤404A中确定原始HTTP请求要访问的域名与应用的域名相同；如果 否，则在步骤405A中确定原始HTTP请求要访问的域名与应用的域名不同。需要指出的是， 应用域名列表是指已经存在的记录下所有应用的域名的表格，这种判断方法在所提供的应 用的数量有限且较为固定的情形下具有优势，只要将HTTP请求的URL地址的域名部分通过 查表与应用域名列表中列举的域名一一比对，即可确定原始HTTP请求要访问的域名与应 用的域名是否相同。
下面参考图4B所示的根据本发明另一判断原始HTTP请求的域名与应用的域名是 否相同的实施例。步骤401B和402B对应于401A和402A，分别是获取HTTP请求的URL地 址和分析所获取的URL地址的域名部分，在此不再详述。与图4a所示的实施方式不同的是， 在步骤403B中，判断所获取的URL中的域名部分的模式与预定义的新域名模式是否相同。 如果是，则在步骤404B中确定原始HTTP请求要访问的域名与应用的域名不同；如果否，则 在步骤405B中确定原始HTTP请求要访问的域名与应用的域名相同。本领域技术人员应 当了解，当所提供的应用的数量较多或者动态变化的情形下，图4B所示的判断方法具有优 势。这是因为，如果应用的数量较多或者动态变化，将难以实时地把所有应用的域名一一预 先记录，而通过比较原始HTTP请求的URL的域名部分的模式与预定义的新域名的模式，可 以判断出原始HTTP请求要访问的域名是否与应用的域名相同。新域名模式的具体示例在 图2的文字描述中已有记载，在此不作过多描述。图5示出了根据本发明一个实施方式的用于处理客户端所提交的HTTP请求的方 法的流程图。其中，步骤501至步骤504已经在上文对图2至图4的描述中有过详细记载， 这里重点描述客户端与服务器建立通信后HTTP会话被隔离的过程。在步骤505中，应用的服务器为新的HTTP请求生成HTTP会话标识(session id)， 并将会话标识返回至发出所述原始HTTP请求的客户端。本领域技术人员应当了解，此步骤 是由HTTP协议规范决定的，对于任何HTTP请求，根据会话机制，当客户端初次连接服务器 时，在服务器建立HTTP会话并保存与该会话相关的变量，同时产生一个HTTP会话标识(ID) 用来识别该会话的变量。在步骤506，一旦应用的服务器将HTTP会话标识发送至客户端，客户端就记录所 述会话标识和修改后的域名的对应关系。本领域技术人员应当了解，根据HTTP协议规范， 客户端可以自动在本地cookie中记录会话标识和域名的对应关系。在步骤507中，如果客 户再次访问同一应用实例，那么客户端所提交的HTTP请求中就自动包含了之前已经修改 过并记录下来的对应于该应用实例的新HTTP请求(参见步骤507)，并且包含了与新HTTP 请求要访问的域名所对应的HTTP会话标识(session id)(参见步骤508)。那么在步骤509 中，客户端将HTTP会话标识和HTTP请求一起发送至应用(参见图3的步骤302和307，当检 测到这样的原始HTTP请求要访问的域名与应用的域名不同时，直接将原始HTTP请求发送 至所述应用)，从而利用所述会话标识与应用建立通信。由于对于不同的应用实例，修改且 记录的新的域名是不同的，因此由应用的服务器分配的会话标识也是不同的，这样客户端 请求访问同一应用的不同应用实例时就可以利用不同的会话标识与应用建立HTTP通信。需要指出的是，尽管图5所示的流程图中示出了应用服务器生成HTTP会话标识并 将会话标识发送至客户端、客户端记录会话标识与域名的对应关系、客户端再次访问同一 实例时向应用发送之前生成的会话标识以及之前记录的新域名等步骤(参见步骤505至 509)，并不意味着上述步骤是本发明的必要步骤。本领域技术人员可以了解，本发明的多个 实施方式正是利用现有技术中的HTTP协议规范(包括生成HTTP会话标识以及在cookie 中记录会话标识，并且再次访问时自动发送所述会话标识)的内容，通过在访问某应用实 例的原始HTTP请求要访问的域名与应用的域名相同的情况下修改原始HTTP请求的域名， 来获得不同的HTTP会话标识，从而实现隔离HTTP会话的目的。也就是说，上述步骤505至 509是由现有技术中的HTTP协议规范决定的，必须建立在步骤503修改域名的基础上才能实现隔离HTTP会话的目的，记载步骤505至509的目的是为了详细描述隔离HTTP会话的 全过程，它们并不构成本发明的实施方式所提供的技术方案中的技术特征的一部分。图6示意性地示出了根据本发明一个实施方式的记录与新域名相关信息的表。根 据上文的描述，客户端初次访问某应用实例时的HTTP请求中的域名部分会被修改为新的 域名，从而生成新的HTTP请求，而客户端以后再次访问同一应用实例时就可以利用已经生 成并记录下来的新域名发出fflTP请求，并且利用已经由应用的服务器生成的对应于新的 HTTP请求的会话标识与应用服务器建立通信。那么根据本发明的一实施例，可以限定并记 录新域名的有效期限，并且记录访问某实例的最后访问时间。也就是说，限定之前已经被记 录下来的新域名仅在一定时间期限内有效，超过这一期限后，即使客户端再次访问同一应 用实例，也不能利用已有的新域名和已经的HTTP会话标识与应用服务器建立通信，而是需 要重新发出包含与应用的域名相同的域名部分的原始HTTP请求，并再次对其进行修改以 生成新的HTTP请求。此实施方式对于提高网络应用访问系统的安全性是有帮助的。具体 地，参考图6示出的表，某应用具有两个应用实例，分别是公司A的实例和公司B的实例，最 后访问公司A实例的时间是2008年1月23日16:05分，对应于公司A的新域名的时间期 限是15分钟；最后访问公司B实例的时间是2008年1月23日16:08分，对应于公司B的 新域名的时间期限是23分钟。假设当前时间是2008年1月23日16 30分，客户端再次提 交访问公司A实例的请求，那么检测到已超出15分钟的新域名有效期限，于是提交包含域 名oa.wds.com的HTTP请求，并对其进行修改。假设同样在2008年1月23日16:30分，客 户端再次提交访问公司B实例的请求，那么检测到尚未超出23分钟的新域名有效期限，于 是提交包含域名XEQIES23. oa. wds. com的HTTP请求，无需对其进行修改，直接发送至应用 的服务器。图7示出了根据本发明一个实施方式的用于处理HTTP请求的系统的框图。该系 统在图7中总体上由700表示。具体地，系统700包括接收模块701，域名修改模块702和 发送模块703。接收模块701用于接收要对应用的实例进行访问的原始HTTP请求。域名修 改模块702用于在所述原始HTTP请求的域名与应用的域名相同的情况下，将原始HTTP请 求的域名修改为新域名，以生成要对所述应用的实例进行访问的新的HTTP请求。其中利用 泛域名技术使得新域名与原始HTTP请求的域名指向相同的IP地址——应用的IP地址，只 有这样才能保证客户端对应用的正确访问。发送模块703用于将包含新域名的新的HTTP 请求发送至所述应用的服务器以对所述应用的实例进行访问。图7所示的系统包含的模块 701-703可以理解为分别对应于图2所示的方法的步骤201-203，具体的修改域名的实施方 式、以及对修改后的新域名的模式限制等内容可参考图2的文字描述部分的详细记载。图8示出了根据本发明另一实施方式的用于处理HTTP请求的系统的框图。图8所 示的系统在总体上由800表示。具体地，系统800包括接收模块801，域名判断模块802，域 名修改模块803，返回模块804，发送模块805和记录模块806。接收模块801、域名修改模 块803和发送模块805分别对应于图7所示的系统中的模块701-703，也对应于图2所示的 方法中的步骤201-203。可以理解域名判断模块802对应于图3所示的步骤302，该模块用 于判断由接收模块801接收到的访问应用实例的原始HTTP请求要访问的域名是否与应用 的域名相同。在域名判断模块输出判断结果为是情况下，由域名修改模块803对域名进行 修改，并由返回模块804将修改后的新域名返回至客户端。域名判断模块802可以利用图4a和图4b所示的实施方式进行判断，具体判断的方法已在图4的文字描述部分详细记载。 需要指出的是，在此实施方式中，接收模块801除了接收原始HTTP请求外，也要接收客户端 重新提交的新的HTTP请求。发送模块805用于将新的HTTP请求发送至应用，还用于在域 名判断模块802的输出为“否”的情况下，直接将原始HTTP请求发送至应用。记录模块806 用于记录对应用实例访问的最后时间以及对应于该应用实例的新域名的有效期限等信息， 具体内容可以参照图6所示的记录表。图9示出了根据本发明另一实施方式的用于处理客户端所提交的HTTP请求的方 法的流程图。根据本发明一实施方式的用于处理HTTP请求的系统可以部署于应用服务器 侧。该系统用于实现图2至图5所示的方法。本领域技术人员可以了解，该系统也可以部 署于应用服务器之外，只要该系统可以在HTTP请求到达应用服务器之前接收该HTTP请求 并对其进行处理即可。如图9所示，用户(例如一家会计师事务所)登录应用门户网站mm. wds. com,该 门户网站可以提供多个应用服务，例如包括会计服务、人力资源管理服务、IT服务等等。这 些应用服务可以是软件即服务SaaS。然后用户点击该应用门户网站上提供的多种应用之 一例如会计服务，该会计服务的域名是oa. wds. com，用户进入会计服务的主页后，通过客户 端浏览器点击公司A的应用实例来对公司A提供会计服务。用户点击了页面上的“公司A” 之后，发出一个HTTP请求，该HTTP请求要访问的URL地址是HTTP://oa. wds. com/oa ？ sid 三互，用于隔离HTTP会话的系统接收到这个HTTP请求，分析出该HTTP请求要访问的域名是 oa. wds. com(域名是指URL地址中HTTP://之后并且“/”之前的部分)，并且判断出该域名 与会计服务的应用的域名相同，于是将该域名修改为SZQIES12. oa. wds. com，并将包含了修 改后的域名的新HTTP请求返回至客户端浏览器，客户端自动在本地记录该修改后的域名， 然后重新发送新的HTTP请求。用于隔离HTTP会话的系统接收到这个新的HTTP请求后，判 断出该HTTP请求的域名部分不是应用的域名，于是向应用的服务器发送该HTTP请求。需要 指出的是，用于隔离HTTP会话的系统还可以既将包含了修改后的域名的新HTTP请求返回 至客户端浏览器，又将包含了修改后的域名的新HTTP请求发送至应用的服务器，而不需要 由客户端重新发送新的HTTP请求。之后，根据HTTP协议规范，应用服务器响应该新的HTTP 请求，并为域名SZQIES12. oa. wds. com生成对应的HTTP会话标识(session id) CDWDUWE,并 将该会话标识随着HTTP响应发送至客户端，由客户端浏览器记录在“公司A”实例的cookie 中。同样地，从图9可以看出，当用户在会计服务应用主页中点击标签“公司B”后，应 用服务器为修改后的域名XEQIES23. oa. wds. com生成对应的HTTP会话标识(session id) CDWDUST,并将该会话标识随着HTTP响应发送至客户端，由客户端浏览器记录在“公司B”实 例的cookie中。接下来，当用户再次点击“公司A”标签时，由于客户端已经记录了修改后的新域名 SZQIES12. oa. wds. com,因此自动以新域名发送HTTP请求，并且发送之前在客户端cookie 中记录下来的对应的HTTP会话标识(session id) CDWDUWE。根据本发明一实施方式的系统 判断出该HTTP请求的域名部分不是应用的域名oa. wds. com,于是直接将该HTTP请求发送 至会计服务应用，会计服务应用服务器利用接收到的会话标识CDWDUWE对该HTTP请求进行 响应。
同样地，虽然图9中没有示出，本领域技术人员也可以了解，当用户再次点击“公 司B”标签时，执行上述类似的操作。此外，虽然在上面示出的实施方式中，结合SaaS应用来描述本发明，但这只是示 例性的，本发明并非仅限于此。本发明中的应用可以是任何适当的应用，诸如像电子邮件应 用、网上银行应用等一般的网络应用。另外，虽然在上面示出的实施方式中，描述了本发明在一个浏览器实例的情况下 的应用，但并不应当将其理解为是对本发明的限制。实际上，本发明适应用于在一个HTTP 会话中需要运行同一应用的多个服务实例的环境，而与并非只是单个浏览器实例的情况。 如果浏览器被设计为多个浏览器实例共享一个HTTP会话，则依然能够应用本发明。此外，虽然在上面示出的实施方式中，结合IFrame对本明进行了详细描述，这只 是出于说明的目的。实际上，本发明并不仅限于IFrame，本发明还可以应用于具有例如选项 卡等任何其他适当的用户接口组件的环境中。利用本发明的方法，通过将访问同一应用的不同实例的HTTP请求的域名部分修 改为新的域名，实现了对现有技术中的HTTP会话的隔离，从而得到了与各个服务实例对应 的子会话。在与服务器进行通信时，各个服务实例使用与其对应的HTTP子会话，从而使得 服务器能够通过各个HTTP会话标识识别出各个服务实例，进而确保了数据的正确性，避免 了现有技术中引起的混淆，并且这对于用户是透明的，从而带来了良好的用户体验，更好地 满足了商业的需求。通过以上对具体实施例的描述，本领域技术人员可以理解，上述的系统、装置和方 法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、 CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电 子信号载体的数据载体上提供了这样的代码。本实施例的装置、服务器及其单元可以由诸 如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门 阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理 器执行的软件实现，也可以由上述硬件电路和软件的结合实现。虽然以上结合具体实施例，对本发明的利用远程应用处理本地文件的系统及方法 进行了详细描述，但本发明并不限于此。本领域普通技术人员能够在说明书教导之下对本 发明进行多种变换、替换和修改而不偏离本发明的精神和范围。应该理解，所有这样的变 化、替换、修改仍然落入本发明的保护范围之内。本发明的保护范围由所附权利要求来限定。
权利要求
1.一种用于处理超文本传输协议HTTP请求的方法，包括接收要对应用的实例进行访问的原始HTTP请求；如果所述原始HTTP请求要访问的域名与所述应用的域名相同，将所述原始HTTP请求 要访问的域名修改为与所述应用的域名不同的新域名，以生成要对所述应用的实例进行访 问的新的HTTP请求，并且将所述新的HTTP请求发送至所述应用的服务器以对所述应用的 实例进行访问，其中所述原始HTTP请求要访问的域名和所述新域名对应于相同的IP地址。
2.如权利要求1所述的方法，还包括如果所述原始HTTP请求要访问的域名与所述应 用的域名不同，直接将所述原始HTTP请求发送至所述应用的服务器以对所述应用的实例 进行访问。
3.如权利要求1或2所述的方法，还包括将所述新的HTTP请求返回至发出所述原始 HTTP请求的客户端。
4.如权利要求1或2所述的方法，还包括获取所述原始HTTP请求的URL，并分析所获 取的URL中的域名部分以判断所述原始HTTP请求要访问的域名是否与所述应用的域名相 同。
5.如权利要求4所述的方法，如果所获取的URL中的域名部分与预定义的应用域名列 表中的域名相同，则确定所述原始HTTP请求要访问的域名与所述应用的域名相同。
6.如权利要求4所述的方法，如果所获取的URL中的域名部分的模式与预定义的新域 名模式不同，则确定所述原始HTTP请求要访问的域名与所述应用的域名相同。
7.如权利要求1-6任一所述的方法，其中将所述原始HTTP请求要访问的域名修改为与 所述应用的域名不同的新域名包括向所述原始HTTP请求的URL的头部加入随机产生的符 号。
8.如权利要求7所述的方法，所述随机产生的符号符合预定义的新域名模式。
9.如权利要求1-8任一所述的方法，还包括记录如下内容所述新域名、根据所述新域 名对所述应用进行最后一次访问的时间以及将所述新域名设置为无效域名的时间期限。
10.如权利要求9所述的方法，还包括根据所记录的最后一次访问的时间和所记录的 时间期限，判断是否保持当前接收到的新域名有效，如果判断结果为否，将所述当前接收到 的新域名视为与所述应用的域名相同的原始域名。
11.如权利要求1-10任一所述的方法，对于请求对同一应用的不同实例进行访问的不 同的原始HTTP请求，所修改得到的新域名各不相同，其中不同的原始HTTP请求要访问的域 名与所述同一应用的域名相同。
12.如权利要求1-11任一所述的方法，所述应用是软件即服务应用。
13.一种用于处理超文本传输协议HTTP请求的系统，包括接收模块，用于接收要对应用的实例进行访问的原始HTTP请求；修改模块，被配置为如果所述原始HTTP请求要访问的域名与所述应用的域名相同，将 所述原始HTTP请求要访问的域名修改为与所述应用的域名不同的新域名，以生成要对所 述应用的实例进行访问的新的HTTP请求；以及发送模块，被配置为将所述新的HTTP请求发送至所述应用的服务器以对所述应用的 实例进行访问，其中所述原始HTTP请求要访问的域名和所述新域名对应于相同的IP地址。
14.如权利要求13所述的系统，所述发送模块还被配置为如果所述原始HTTP请求要访问的域名与所述应用的域名不同，直接将所述原始HTTP请求发送至所述应用的服务器以 对所述应用的实例进行访问。
15.如权利要求13或14所述的系统，还包括返回模块，被配置为将所述新的HTTP请求 返回至发出所述原始HTTP请求的客户端。
16.如权利要求13或14所述的系统，还包括判断模块，用于获取所述原始HTTP请求 的URL，并分析所获取的URL中的域名部分以判断所述原始HTTP请求要访问的域名是否与 所述应用的域名相同。
17.如权利要求16所述的系统，所述判断模块被进一步配置为如果所获取的URL中 的域名部分与预定义的应用域名列表中的域名相同，则确定所述原始HTTP请求要访问的 域名与所述应用的域名相同。
18.如权利要求16所述的系统，所述判断模块被进一步配置为如果所获取的URL中 的域名部分的模式与预定义的新域名模式不同，则确定所述原始HTTP请求要访问的域名 与所述应用的域名相同。
19.如权利要求13-18任一所述的系统，所述修改模块被进一步配置为通过向所述原 始HTTP请求的URL的头部加入随机产生的符号，来将所述原始HTTP请求要访问的域名修 改为与所述应用的域名不同的新域名。
20.如权利要求19所述的系统，所述随机产生的符号符合预定义的新域名模式。
21.如权利要求13-20任一所述的系统，还包括记录模块，被配置为记录如下内容所 述新域名、根据所述新域名对所述应用进行最后一次访问的时间以及将所述新域名设置为 无效域名的时间期限。
22.如权利要求21所述的系统，所述判断模块被进一步配置为根据所记录的最后一 次访问的时间和所记录的时间期限，判断是否保持当前接收到的新域名有效，如果判断结 果为否，将所述当前接收到的新域名视为与所述应用的域名相同的原始域名。
23.如权利要求13-22任一所述的系统，所述修改模块被进一步配置为对于请求对同 一应用的不同实例进行访问的不同的原始HTTP请求，所修改得到的新域名各不相同，其中 不同的原始HTTP请求要访问的域名与所述同一应用的域名相同。
24.如权利要求13-23任一所述的系统，所述应用是软件即服务应用。
全文摘要
本发明涉及超文本传输协议(HTTP，Hypertext Transfer Protocol)会话技术，尤其涉及用于处理HTTP请求的方法和系统。本发明提供了一种用于处理HTTP请求的方法，包括接收要对应用的实例进行访问的原始HTTP请求；如果所述原始HTTP请求要访问的域名与所述应用的域名相同，将所述原始HTTP请求要访问的域名修改为与所述应用的域名不同的新域名，以生成要对所述应用的实例进行访问的新的HTTP请求，并且将所述新的HTTP请求发送至所述应用的服务器以对所述应用的实例进行访问，其中所述原始HTTP请求要访问的域名和所述新域名对应于相同的IP地址。从而避免现有技术中在同一超文本传输协议会话中运行同一应用的多个服务实例时出现的诸如数据混淆、数据错误、使用不便等各种问题。
文档编号H04L29/08GK101997903SQ20091017095
公开日2011年3月30日 申请日期2009年8月27日 优先权日2009年8月27日
发明者向哲, 崔洁, 张剑鸣, 王斌 申请人:国际商业机器公司