掌桥专利:专业的专利平台
掌桥专利
首页

用于在协同浏览会话中访问专有资源的方法和装置

文献发布时间:2023-06-19 11:27:38


用于在协同浏览会话中访问专有资源的方法和装置

本申请要求题为《在协同浏览会话中访问专有资源》、于2018年11月21日提交的美国临时专利申请62/770493的优先权,其内容通过引用合并于此。

本专利文献的部分公开内容包含受版权保护的题材。版权所有者不反对任何人以本专利文献或专利公开呈交于专利商标局的文档或记录中的确切形式来进行静电复制,但将保留其他任何方面的一切版权权利。

技术领域

本领域涉及通信会话,更具体地,涉及用于在协同浏览会话中访问专有资源的方法和装置。

背景技术

可以在地理位置较远的第二浏览器中共享并再现第一浏览器的内容。一种实现方法是使描述第一浏览器的内容的文档对象模型(DOM)转发给第二浏览器。第二浏览器使用从第一浏览器中接收到的DOM来重新创建第一浏览器的内容。

不幸的是,在某些情况下,仅具有DOM不足以使第一浏览器的所有内容可靠地再现在第二浏览器处。特别地,根据网站的构建方式,在第一浏览器中显示的内容可以基于诸如字体、层叠样式表(CSS)和图像之类的资源,这些资源需要cookie来访问并因此仅适用于第一浏览器。由于第二浏览器无法从该网站中获得相同的专有资源,因此第二浏览器的内容将无法正确反映第一浏览器中显示的内容。此外,某些网站使用跨域资源共享(CORS)头来阻止另一个域上的浏览器访问网站资源。在这种情况下,CORS阻止代理查看器直接从网站中访问资源,但可以通过“资源获取过程”访问该资源。因此,提供一种使得可以在协同浏览会话中由第二浏览器访问第一浏览器的专有资源的系统将是有利的。

发明内容

在此提供发明内容和摘要部分,以介绍在下面具体实施方式中所讨论的一些概念。发明内容和摘要部分并不全面,并且不旨在描述受保护主题的范围,该范围由下面提出的权利要求所阐述。

在一些实施例中,协同浏览服务实现资源获取过程,以使代理浏览器可以在协同浏览会话中访问在访客浏览器上使用的专有资源。将访客的DOM的一些或所有的资源URL(全球资源定位器)转换为指向资源获取过程,以便代理浏览器试图从资源获取过程中而非从网站中检索URL引用的资源。资源获取过程进而从网站或访客中获取资源。由于资源获取过程能代表代理获取专有资源,并在协同浏览会话期间向代理提供专有资源,因此代理能在协同浏览会话期间具有与访客浏览器一致的视图。

附图说明

本发明的各个方面将在所附权利要求书中具体指出。本发明由下面附图中的示例阐明,其中相似的附图标记指示相似的元件。以下附图公开本发明的各种实施例,其仅为说明性目的而不旨在限制本发明的范围。为清楚起见,每个附图中并未对所有的组件进行标记。在附图中:

图1是根据一些实施例的用于在协同浏览会话中访问专有资源的组件的网络的功能框图。

图2是根据一些实施例的泳道图,其示出图1的数个组件之间的信息传输,其与在协同浏览会话上提供专有资源有关。

具体实施方式

下面的详细描述阐述许多具体细节,以提供对本发明的一个或多个实施例的深入理解。然而,本领域的技术人员应当理解,本发明无需这些具体细节即可实施。在其他实例中,为了不对本发明造成混淆,没有对公知的方法、过程、组件、协议、算法和电路进行详细描述。

图1是根据一些实施例的用于在协同浏览会话132中访问专有资源的组件的网络100的功能框图。如图1所示,在一些实施例中,网络服务器110主控网站115。访客120使用访客浏览器125访问网站115,以从网络服务器110中加载网页。协同浏览服务130促进协同浏览会话132,代理135在该协同浏览会话132中能在代理浏览器140中查看访客浏览器125的内容。

在一些实施例中,用协同浏览JavaScript 145编写从网络服务器110中加载的网页脚本。可替代地,可以将协同浏览JavaScript 145作为插件或扩展加载到访客浏览器125。协同浏览JavaScript 145使描述加载到访客浏览器125中的网页的文档对象模型(DOM)转发给协同浏览服务130。协同浏览服务130将DOM转发给协同浏览会话132中的代理浏览器140,以使代理浏览器140具有与访客浏览器125的内容一致的视图。如何实现这种性质的示例协同浏览系统的额外细节提供在题为《INTEGRATING CO-BROWSING WITH OTHERFORMS OF INFORMATION SHARING》的美国专利第9,736,214号中,其内容通过引用合并于此。

当代理浏览器140接收到描述访客浏览器125的内容的DOM时,代理浏览器140通常将从网站115中请求DOM中描述的资源。但是,在某些情况下,代理浏览器140将不能从网站115中获得与访客浏览器125能从网站115中获得的资源相同的资源。例如,根据构建网站115的方式,访客浏览器125可以具有字体、层叠样式表(CSS)以及图像,其仅提供给呈现cookie的客户端,例如访客浏览器125。同样地,在代理浏览器140执行与网站115不同域的网络应用的情况下,跨域资源共享(CORS)限制可能会阻止代理浏览器140访问网站115上的受限制资源。如本文所使用的,术语“专有”定义为指受Cookie和/或CORS保护的资源。

例如,许多公司在其网站上具有协同浏览会话132中的代理浏览器140无法访问的资源。一些典型场景包含无法被跨域访问的字体或CSS。因此,如果代理浏览器140在一个域上并且资源在另一个域上,则CORS限制可以阻止代理浏览器140访问资源。作为另一个示例,资源可以是访客浏览器125所特有的图像,诸如银行支票图像之类的帐户特定的图像,其可能需要代理浏览器140不具有的并且协同浏览服务130也不具有的会话cookie。

根据一些实施例,协同浏览服务130为协同浏览会话132实例化资源获取过程150。协同浏览JavaScript 145复制浏览器125的DOM,并将DOM转发给协同浏览会话132中的协同浏览服务130。代理浏览器140接收协同浏览会话132中转发的DOM,并从资源获取过程150中而非从网站115中请求DOM中引用的至少一些资源。资源获取过程150通过向网站115和访客浏览器125两者提交对资源的请求,来服务资源请求。当资源获取过程150从访客浏览器或网站中接收到资源时,其将所请求的资源返回给代理浏览器140。使用资源获取过程150使得能代表代理浏览器140获得专有资源,以便代理浏览器140能更紧密地复制访客浏览器125的内容。

图2是根据一些实施例的泳道图,其示出图1的数个组件之间的信息传输,其用于在协同浏览会话132中访问专有资源。如图2所示,在箭头200处,访客浏览器125从网站115中下载网页和协同浏览JavaScript 145。在箭头205和210处,开始协同浏览会话132。有许多开始协同浏览会话132的方式。例如,访客浏览器125可以启动协同浏览会话132,然后由代理浏览器140加入该协同浏览会话132;代理可以触发访客以启动会话,然后由该代理加入该对话;或者代理浏览器140可以启动协同浏览会话132,然后访客浏览器125可以以显示模式加入协同浏览会话132。不管如何开始协同浏览会话132,根据一些实施例,协同浏览服务130实例化资源获取过程(箭头215),在协同浏览会话132期间由代理浏览器140使用该资源获取过程,以访问访客浏览器125的共享DOM中指定的至少一些资源。

在一些实施例中,访客协同浏览JavaScript 145将访客浏览器125的DOM的URL转换为指向资源获取过程150。根据一些实施例,一旦已经实例化资源获取过程150以在协同浏览会话132中使用,就将资源获取过程150的URL转发给访客浏览器125(箭头220)。可替代地,在一些实施例中,访客协同浏览JavaScript145可以基于用于主控协同浏览会话132的协同浏览服务130处的服务器(例如[协同浏览服务器]/代理/资源/[会话ID])来获得资源获取过程150的URL。访客浏览器125使用资源获取过程150的URL来转换DOM中的相对资源URL和绝对资源URL,以使这些URL指向资源获取过程150(箭头225)。尽管一些实施例具有由访客浏览器125中的协同浏览JavaScript 145实现的URL转换,但是在其他实施例中,URL转换是例如由代理浏览器140、协同浏览服务130或由资源获取过程150在网络100的另一组件处完成的。

在其中URL转换过程是在访客浏览器处实现的实施例中,一旦由访客协同浏览JavaScript 145转换了DOM中引用的正确的URL集,就将修改后的DOM从访客浏览器125转发到协同浏览服务130(箭头230),并将修改后的DOM从协同浏览服务130转发到代理浏览器140(箭头235)。在其中URL转换是在协同浏览服务130处完成的实施例中,访客协同浏览JavaScript将访客浏览器125的DOM转发给协同浏览服务130(箭头230),协同浏览服务130实现URL转换过程,并将修改后的DOM转发给代理浏览器140(箭头235)。

在其中URL转换过程是在代理浏览器140处实现的实施例中,协同浏览服务130将资源获取过程150的URL转发给访客浏览器125(箭头220’)。可替代地,在一些实施例中,代理浏览器140可以基于用于主控协同浏览会话132的协同浏览服务130处的服务器(例如[协同浏览服务器]/agent/resource/[会话ID])来获得资源获取过程150的URL。一旦代理浏览器140具有资源获取过程150的URL,代理浏览器140就可以实现URL转换过程,以使DOM中引用的至少一个URL的子集指向资源获取过程150。

不管在何处实现URL转换过程,在URL转换之后,加载到代理浏览器140的修改后的DOM的一些或全部URL将指向资源获取过程150。因此,当代理浏览器140试图加载由DOM描述的网页时,代理浏览器140将向资源获取过程150发出一些或全部资源请求(箭头240)。

在一些实施例中,将DOM的所有URL转换为指向资源获取过程150。在这些实施例中,代理浏览器140从资源获取过程150中请求DOM中引用的所有资源(箭头240)。

在其他实施例中,将DOM的URL的第一子集转换为指向资源获取过程150。在这些实施例中,代理浏览器140从资源获取过程150中请求资源的第一子集(箭头240),并且代理浏览器140从网站115中请求其他资源(箭头242)。因此,当修改后的DOM的仅一些URL指向资源获取过程150时,当代理浏览器140试图加载由DOM描述的网页时,代理浏览器140将向资源获取过程150发出与转换后的URL相关联的资源请求(箭头240),并将以正常方式向网站115发出未转换的URL的资源请求(箭头242)。

当资源获取过程150接收到资源请求时(箭头240),如果资源获取过程150已经缓存所请求的资源,则资源获取过程150会将所请求的资源转发给代理浏览器140(箭头245)。如果资源获取过程150先前未获得并缓存所请求的资源,则资源获取过程150从网站115中请求资源(箭头250),从访客浏览器125中请求资源(箭头255),或从网站115和访客浏览器125两者中请求资源(箭头250、255)。

在一些实施例中,资源获取过程150从网站115和访客浏览器125两者中请求资源,而无需先等待来自一个或另一个的响应。例如,在一些实施例中,资源获取过程150向访客浏览器125要求资源(箭头255),并且在接收到来自访客浏览器125的响应(箭头270)之前,还向网站115发送相同资源的请求(箭头250)。同样地,在一些实施例中,资源获取过程150向网站115要求资源(箭头250),并且在接收到来自网站115的响应(箭头260)之前,还向访客浏览器125发送相同资源的请求(箭头255)。

在某些情况下,资源获取过程150可从网站115中获得所请求的资源。如果所请求的资源可从网站115中获得,则网站115将所请求的资源转发给资源获取过程150(箭头260),并且资源获取过程150通过将所请求的资源转发给代理浏览器140来满足资源请求(箭头265)。在一些情况下,资源获取过程150可从访客浏览器125中获得所请求的资源。如果所请求的资源可从访客浏览器125中获得,则访客浏览器125将所请求的资源转发给资源获取过程150(箭头270),并且资源获取过程150通过将所请求的资源转发给代理浏览器140来满足资源请求(箭头275)。

在某些情况下,尽管访客浏览器125在其缓存中将已经具有所请求的资源,但是浏览器中的JavaScript无法访问作为平面文件形式的这些资源。例如,浏览器可具有加载的字体,并且CSS可能引用该字体,但是JavaScript没有对该字体文件的句柄。在这种情况下,访客浏览器125向网站115提出针对文件的XMLHttpRequest(XHR请求)(箭头280)。访客浏览器125实际上可以从缓存中提取实际文件,或者,如果资源来自不同域的网站115,则访客浏览器125可能必须使用CORS头向网站115重新发出请求。当获得所请求的资源时(箭头285),然后将其转发给资源获取过程150(箭头270),然后转发给代理浏览器140(箭头275)。

在某些情况下,资源获取过程150将可从网站115和访客浏览器125两者中获得所请求的资源。在一些实施例中,当资源获取过程150从网站115接收到第一响应(箭头260)时,或从访客浏览器125中接收到第一响应(箭头270)时,资源获取过程150将响应转发给代理浏览器140(箭头265或275),以满足资源请求。可选地,一旦从一个源接收到资源,就可以取消对另一源的请求。

在某些情况下,资源获取过程150将从网站115(箭头260)和访客浏览器125(箭头270)两者中接收响应。在一些实施例中,如果两个响应都返回超文本传输协议(http)状态200(ok),则该两个响应通常是等效的,并且资源获取过程150可以选择二者中的任一响应来满足代理浏览器140的资源请求。一种例外是,如果其中一个响应返回内容类型的文本/超文本标记语言(text/html)而非预期的图像、字体或CSS内容类型。通常,这意味着网络服务器110返回错误页面,而非资源本身。在一些实施例中,如果访客浏览器125或网站115返回错误,并且另一个返回http状态200(ok),则使用具有状态200的答复。如果二者均返回http错误状态代码,那么可以选择其中一个响应,例如具有较低错误代码的响应,但是在这种情况下如何选择响应可能会因实现方式而异。

在一些实施例中,资源获取过程150缓存网站115的资源,并将网站资源提供给代理浏览器140(箭头245)。

在一些实施例中,当将超文本标记语言(html)上传到协同浏览服务130时,访客协同浏览JavaScript 145调整标签和资源URL,以便通过资源获取过程150来将全部的相关网站资源请求重定向。访客协同浏览JavaScript 145还将所有绝对的超文本引用(href)和源(src)属性转换为相对属性,以便当与标签结合时,href或src URL将指向资源获取过程150上的URL。

当资源获取过程150从代理浏览器140接收到对网站资源的请求时,资源获取过程150提供来自其本地缓存中的网站资源(箭头245)。如果资源获取过程150尚未具有资源,则它通过在访客计算机120的sockjs连接上发送消息,来从访客浏览器125中请求资源(箭头255)。如果访客浏览器125当前未连接到协同浏览会话132,例如因为访客正在跳转到新页面,则资源获取过程150在下次连接访客浏览器125时,将请求添加到要由访客协同浏览JavaScript 145处理的会话状态。资源获取过程150还直接从网络服务器110中请求资源(箭头250)。

访客浏览器125将资源上传到资源获取过程150(箭头270)和/或网络服务器110用该资源来响应资源获取过程150(箭头260)。资源获取过程150将资源存储在会话特定的区域中。资源获取过程150扫描由访客浏览器125上传的或由网络服务器110返回的任何CSS文件,查找图像、字体或其他CSS文件的URL,并将CSS文件中的绝对URL转换为相对URL。

在一些实施例中,缓存用于存储特定于单个访客120的资源。在一些实施例中,资源获取过程150在协同浏览会话132的结尾移除所有缓存的资源。在其他实施例中,公共缓存用于存储共同请求的资源,以使那些共同请求的资源能够从具有多个访客120的协同浏览会话132的缓存中获得。在这种情况下,缓存的资源可能不会在协同浏览会话132结束时被移除。

结合转换网页的URL,在一些实施例中,访客协同浏览JavaScript 145添加以下基本标签,使得页面上的相对URL全部指向主控资源获取过程150的协同浏览服务130处的服务器:

如果页面已经具有带有href的基本标签,则访客协同浏览JavaScript 145将其修改为指向主控资源获取过程150的协同浏览服务130处的服务器。例如:

修改为

请注意,通过进行一些替换来将绝对URL映射到URL路径项:

://or//maps to-/

这允许这些URL看起来像代理浏览器140的相对URL,而资源获取过程150仍然能将它们映射回原始URL。在一些实施方式中,该映射是在访客协同浏览JavaScript 145中的JavaScript函数中的访客侧实现的。对于iframe,“框架路径”也将被插入到基本标签中。请参阅下面有关iframe的部分。

在一些实施例中,将标签中的绝对URL转换为相对URL,以便代理浏览器140将对那些资源的请求发送到资源获取过程150。例如:

修改为:

在一些实施例中,类似地修改src和srcset属性。

在一些实施例中,协同浏览JavaScript 145仅转换某些类型文件的URL,以便代理浏览器140将直接从网站115中获取未转换的资源。例如,在一些实施例中,访客协同浏览JavaScript 145转换与CSS、img以及字体资源相关的URL,但不转换与网站115的公共可用且访客浏览器125不专有的方面相关的URL。以这种方式,协同浏览服务130不会负担为代理浏览器140获取那些通常可直接从网站115中获得的资源。

当访客协同浏览JavaScript 145上传了CSS文件时,资源获取过程150为绝对URL扫描这些文件。遵循相同的约定,在资源获取过程150中将绝对URL转换为URL。

在一些实施例中,资源获取过程150在调用资源映射中跟踪对访客120的所有未决和完成的资源请求。调用资源映射是以下内容的映射:

resourceURL=>{Future}

除非没有协议,调用资源映射中的resourceURL是绝对URL。无论页面中指定的路径是相对路径还是绝对路径,使用绝对URL都可以重用资源。在本文中,“Future”代表可能已经完成,或在将来的某个时间有待完成的计算任务。

在一些实施例中,对资源获取过程150的资源请求具有用于指定网站上的资源的原始位置的URL的约定。资源请求URL的示例可以是:

/agent/resource/sessionid/[资源路径]。

例如,URL:

/agent/resource/sessionid/https-otherserver.abc.com/a/b/c/style.CSS

将用于请求绝对URL处的资源:

https://otherwserver.abc.com/a/b/c/style.CSS

或:

/resource/sessionid/a/b/c/style.CSS

将用于请求相对URL处的资源:

a/b/c/style.CSS

其中,URL由资源获取过程150解译为相对于访客浏览器125的当前页面。

在一些实施例中,如果代理浏览器140没有为请求中的由协同浏览会话ID指定的协同浏览会话132呈现有效证书,则资源请求以http状态401(未经授权的)被拒绝。

在一些实施例中,资源获取过程150将资源路径映射到文件名,如下所示:

cacheroot/sessionid/[资源路径]

其中,cacherroot是资源获取过程的配置设置,其指示缓存文件的根目录。在一些实施例中,将用下划线代替文件URL中的某些字符,以生成有效的路径名。

当从代理浏览器140中接收到资源请求时,如果在文件缓存中未找到该资源,则资源获取过程150在调用资源映射中查找该资源。在一些实施例中,由资源获取过程在一个会话的上下文中检索的文件可以由资源获取过程结合其他会话来缓存和使用。因此,在一些实施例中,资源获取过程首先确定在URL-future映射中寻找之前是否缓存了资源。如果资源获取过程150从未请求过该资源,则资源获取过程150将这些请求转发给访客浏览器125,如下所示:

消息类型:resreq

消息有效载荷:{URL:[由资源路径确定的绝对URL/相对URL]}

资源获取过程150还将用于该资源的条目添加到调用资源映射中。

如果先前由资源获取过程150请求该资源,但是尚未满足资源请求,则资源获取过程150等待该资源。

如果已经完成资源请求(或当其完成时),则资源获取过程150通过发送文件(如果已成功检索到该文件)来响应该请求。在一些实施例中,将包括在对代理的答复中的缓存头设置为无限期地缓存文件,因为无论如何该文件将仅对协同浏览会话132的长度有效。将资源的内容类型头设置为网络服务器110在向访客浏览器125或向资源获取过程提供资源时最初返回的内容类型(请参阅“资源请求的访客处理”)。无论访客访问器浏览器125或资源获取过程在检索资源时接收何种http状态代码,都会将该http状态代码返回到代理浏览器140。

在一些实施例中,为了阻止恶意JavaScript在代理浏览器140上运行,使用内容安全策略(CSP)头,并且协同浏览服务在提供给代理浏览器140的所有页面上包含CSP头。CSP头限制可以从其中检索JavaScript文件的域(例如到协同浏览服务130),并且还阻止页面中的行内JavaScript运行。因此,CSP兼容的浏览器将仅执行从允许的域列表中接收到的源文件中加载的脚本,忽略所有其他脚本。因此,即使访客120发送恶意脚本试图攻击代理的浏览器140,或者如果恶意脚本以某种方式从网站115中下载,该恶意脚本也不会在代理浏览器140上执行。此外,资源获取进程将对任何JavaScript资源请求返回401错误。

访客浏览器125通过向网站115发出对指定资源的XMLHttpRequest(XHR)请求来处理资源请求(箭头280),并且在接收响应后(箭头285),使用对/访客/UR处的协同浏览服务的POST请求,来将所请求的资源上传到资源获取过程150(箭头270)。在一些实施例中,访客浏览器125将http状态代码和内容类型与该POST一起发送,并且资源获取过程150跟踪该信息。

在一些实施例中,在网络服务器110需要证书来访问资源的情况下,从访客浏览器125到网络服务器110(箭头280)的对资源的XMLHttpRequest(XHR)初始请求包含证书。在某些情况下,网络服务器110不需要证书,并且不允许包含证书的跨域请求。在这种情况下,访客浏览器125可以将错误报告给控制台,而非报告给JavaScript引擎。因此,XHR请求将仅表现为失败,就好像是例如网络连接断开。因此,只要对资源的XHR请求失败而没有http响应,访客浏览器125都会在没有证书的情况下在网络服务器110上重试该请求(在箭头280上重新发送请求)。

在一些实施例中,资源获取过程150具有上传资源(UR)请求处理程序。访客浏览器在协同浏览服务的url上向上传资源处理程序发出POST请求:/visitor/UR/ssnid=[会话id&]url=[资源url]&httpstatus=[http状态码],其中,资源url为资源的url,http状态码是响应于访客对资源的请求由网站返回的状态代码。POST的正文包含资源文件内容。访客浏览器根据对访客资源请求的响应中的内容类型头来设置该请求的内容类型头。如果访客浏览器125成功上传资源,则UR请求处理程序使用上述资源路径到文件路径的映射来将POST的正文保存到文件中。

UR请求处理程序在调用资源映射中查找资源,并通过将其结果设置为资源内容类型(从UR请求上的内容类型头中提取)和http状态(来自httpstatus查询字符串参数)来解析Future。资源获取过程150需要内容类型和http状态,以便响应资源请求。

如果访客浏览器125可能由于CORS错误(由httpstatus 0指示)而无法检索资源,则资源获取过程150自己尝试检索资源。在一些实施例中,资源获取过程150尝试从网络服务器110和访客浏览器125两者中检索资源,而无需先等待访客浏览器125上的请求失败。

访客浏览器125通常应通过发布到UR请求处理程序来响应资源请求,即使其伴随着失败状态。但是,如果:(1)JavaScript错误或网络问题发生并阻止该过程按预期完成,或者(2)访客浏览器125在检索并上传资源之前跳转,则资源获取过程150不应让代理浏览器140无限期地挂起等待回应。例如,Chrome和可能的其他浏览器将不会渲染页面,直到网络服务器110对资源请求提供某种响应为止。因此,如果访客浏览器125在一定时间内未响应资源请求,并且网络服务器110在超时期间内未响应资源,则资源获取过程150将http状态504(网关超时)返回给代理浏览器140。如果访客浏览器125跳转,则取消所有未完成的资源请求Future。

在iframe中引用的资源请求由与该框架关联的“framecall”(即子会话)处理。但是,在顶级调用上仅有一个调用资源映射,以利用可以在iframe之间共享资源这一事实。

为了提供iframe资源,在一些实施例中,定义框架资源获取过程URL(框架路径)。每个框架资源获取过程URL唯一地映射到一个iframe。在一些实施例中,框架资源获取过程URL是从iframe href中获得的,因此,当在访客120侧重新实例化iframe时,框架资源获取过程URL不会改变。框架资源获取过程URL的不变性允许代理浏览器140和资源获取过程150两者重复使用iframe中引用的缓存的资源。

框架资源获取过程URL可以是任何内容,只要它唯一地映射到iframe href。访客协同浏览JavaScript 145选择框架资源获取过程URL,并当框架首次上传其DOM时,将其发送到资源获取过程150。

当访客浏览器125制定标签,以与DOM一起发送给代理浏览器140时,如果访客协同浏览JavaScript 145正在iframe中运行,则访客浏览器125附加/cobrowse-[框架_资源_获取_过程_URL]到发送给代理的基本标签。来自代理浏览器140中的对iframe内的资源的所有资源请求将包含框架资源获取过程URL。

注意,只有引用资源的iframe可以处理资源请求,因为iframe可能与父级不在同一个域中。如果是父级请求资源,其将是“跨域”请求,并且可能会失败。

当资源获取过程150接收到资源请求时,如果URL包含框架资源获取过程URL,则资源获取过程150使用框架资源获取过程URL来识别框架调用。然后,资源获取过程150向访客浏览器125上相应的iframe发出资源请求。如果其是相对于该iframe的location.href的相对URL,则访客浏览器125可以请求该资源。当访客浏览器125接收资源并将该资源上传到资源获取过程150时,访客浏览器125将/visitor/UR URL上的frame_resource_acquisition_process_url包含为附加的frameid查询字符串参数,因此资源获取过程150可以识别资源所属的框架。在一些实施例中,资源获取过程150处理与顶级资源相同的iframe资源,因为资源获取过程150同时从网站115和访客浏览器125中请求它们。

如果iframe中的样式表包括相对URL,则代理浏览器140对资源获取过程150的相对资源请求将为:

/agent/resource/ssnid/frame_resource_acquisition_process_url/path-to-stylesheet/relative-url-for-resource

iframe中的资源存储在文件缓存中的目录ssnid/frame_resource_acquisition_process_url下。

在一些实施例中,如果访客浏览器125在满足未完成的资源请求之前跳转到新页面,则新页面上的协同浏览JavaScript必须承担从网站115中下载那些资源并将其上传到资源获取过程150的工作。为便于实现,资源获取过程150将任何未完成的资源请求添加到会话状态,并在它们被满足时将其删除。访客协同浏览JavaScript 145在页面加载时,满足所有未完成的资源请求。在其他实施例中,如果访客浏览器125在满足未完成的资源请求之前跳转到新页面,则资源获取过程150取消未完成的请求。跳转后,如果新页面使用协同浏览JavaScript编写脚本或者如果访客协同浏览JavaScript 145是持久的(cookie、扩展),则整个过程将为新页面上的资源重新开始。

如果在协同浏览会话132中存在多个代理135,则多个代理135的每个代理浏览器140将为了相同的资源向资源获取过程150发出多个请求。资源获取过程150应确保仅将一个请求(箭头255)转发给访客浏览器125。因此,资源获取过程150将在为相同资源向访客浏览器125发出新请求之前,针对资源的现有的未完成请求来检查协同浏览会话132状态。

某些浏览器可能不支持使用XMLHttpRequest(XHR)请求下载或上传二进制文件。XHR请求是对象形式的API,其方法是在网络浏览器和网络服务器之间传输数据。因此,如果使用这些浏览器之一来实现访客浏览器125,则一种可能的解决方法是将二进制文件下载到具有自定义编码的字符串中。然后,在资源获取过程150处将该字符串解码回二进制。

因为从访客浏览器125获取资源可能需要一些时间,所以在一些实施例中,访客浏览器125为CSS文件扫描页面,并当协同浏览会话132先开始时预加载它们,而不是等待代理浏览器140通过资源获取过程150发出对这些资源的请求。CSS文件对于准确渲染页面(与字体和图像相比)至关重要,因为CSS文件影响整个页面的布局。通过在资源获取过程150处预先缓存CSS文件,当在协同浏览会话132中请求这些资源时,资源获取过程150可以更快地将这些资源提供给代理浏览器140。

本文所述的方法可以实现为经配置以控制逻辑来执行的软件,其例如包含在例如为计算机的电子设备的CPU中。本文所述的功能可以实现为存储在非暂时性有形计算机可读介质中的程序指令集合。当以这种方式实现时,该计算机程序包括一组指令,当该组指令由计算机运行时,其使计算机执行能实施上述功能的方法。可编程逻辑可以暂时或永久地固定在非暂时性有形计算机可读介质中,例如只读存储器芯片、计算机存储器、磁盘或其他存储介质。除了以软件来实现之外,本文所述的逻辑可利用分立组件、集成电路、与可编程逻辑设备(诸如,现场可编程门阵列(FPGA)或微处理器)结合使用的可编程逻辑,或者包括它们任意组合的任何其他设备来体现。所有此类实施例旨在落入本发明的范围之内。

可以在本发明的精神和范围之内可以进行对本说明书所描述以及附图中所示出的实施例的各种变化和修改。因此,意在指出,包含在上述说明中以及示出在附图中的所有内容应当以说明性而非限制性意义来解释。

要求保护的是:

相关技术
  • 用于在协同浏览会话中访问专有资源的方法和装置
  • 用于协同会话中的用户设备间转移的方法、处理器及装置
技术分类

06120112933376