• 关于

    C 编码未响应

    的搜索结果

问题

如何操作GetRange

云栖大讲堂 2019-12-01 20:59:46 1379 浏览量 回答数 0

回答

IVPD服务支持基于URL发送HTTP/HTTPS请求。请求参数需要包含在URL中,请求及返回结果都使用 UTF-8 字符集编码。 以下为一条未编码的URL请求示例: https://ivpd.cn-shanghai.aliyuncs.com/?Action=SegmentImage&<公共请求参数> https : 指定了请求通信协议。 ivpd.cn-shanghai.aliyuncs.com 指定了服务的服务接入地址(Endpoint)。 cn-shanghai: 区域(RegionId), 查看支持的区域。。 Action=SegmentImage: 指定了要调用的API。 <公共请求参数> : 是系统规定的其他公共参数。 公共请求头和公共响应头 API接口中使用了公共请求头(Common Request Headers)和公共响应头(Common Response Headers),这些内容可以被所有的IVPD服务请求使用。 详细说明请参考公共请求参数和公共响应参数。

保持可爱mmm 2020-03-27 01:01:12 0 浏览量 回答数 0

回答

短信服务支持基于URL发送HTTP/HTTPS请求。请求参数需要包含在URL中,请求及返回结果都使用 UTF-8 字符集编码。 以下为一条SendSms未编码的URL请求示例: https://dysmsapi.aliyuncs.com/?Action=SendSms&<公共请求参数> https 指定了请求通信协议。 dysmsapi.aliyuncs.com 指定了短信服务的服务接入地址(Endpoint)。 Action=SendSms 指定了要调用的API。 <公共请求参数> 是系统规定的其他公共参数。 短信发送流程 在控制台中添加签名、模板并经审核通过。 调用短信服务的短信发送接口SendSms或SendBatchSms。 短信服务成功收到请求后转发请求给运营商,运营商发送短信。 用户收到短信后,短信服务会有最终的状态消息确认,即消息回执。 对应的协议是: 支持HTTP或HTTPS协议请求通信。为了获得更高的安全性,推荐您使用HTTPS协议发送请求。 发送API采用Rest协议,其中签名算法使用了阿里云的POP协议。 发送后的消息回执采用是阿里云的消息服务MNS实现。 服务地址 调用API使用的服务地址请参考服务地址。 公共请求头和公共响应头 API接口中使用了公共请求头(Common Request Headers)和公共响应头(Common Response Headers),这些内容可以被所有的短信服务请求使用。 详细说明请参考公共请求参数和公共响应参数。

保持可爱mmm 2020-03-27 00:47:59 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

号码隐私保护支持基于URL发送HTTP/HTTPS请求。请求参数需要包含在URL中,请求及返回结果都使用 UTF-8 字符集编码。 请求结构示例 以下为一条SendSms未编码的URL请求示例: https://dyplsapi.aliyuncs.com/?Action=BindAxb&<公共请求参数> https 指定了请求通信协议。 dyplsapi.aliyuncs.com 指定了号码隐私保护的服务接入地址(Endpoint)。 Action=BindAxb 指定了要调用的API。 <公共请求参数> 是系统规定的其他公共参数。 请求协议 请求中使用的协议包括 支持HTTP或HTTPS协议请求通信。为了获得更高的安全性,推荐您使用HTTPS协议发送请求。 绑定API采用Rest协议,其中签名算法使用了阿里云的POP协议。 发生通话行为后的话单消息回执采用的是阿里云消息服务MNS实现。 服务地址 号码隐私保护统一使用服务地址dyplsapi.aliyuncs.com。 公共请求头和公共响应头 API接口中使用了公共请求头(Common Request Headers)和公共响应头(Common Response Headers),这些内容可以被所有的号码隐私保护请求使用。

保持可爱mmm 2020-03-27 00:22:35 0 浏览量 回答数 0

问题

短信服务,SMS发送中国API,短信验证码发送成功后,手机未收到短信

游客hzquiwvhkfsgc 2019-12-01 19:15:11 135 浏览量 回答数 2

问题

如何使用API

云栖大讲堂 2019-12-01 21:04:08 1458 浏览量 回答数 0

回答

问题原因 1、验签支付宝公钥有误。 2、验签报文存在问题。 3、验签代码方法有误并且未返回成功数据给支付宝。 解决方案 1、验签支付宝公钥有误 检查自己配置的验签使用的公钥(alipay_public_key)是否配置支付宝公钥,验签是使用支付宝公钥,如果使用工具生成的应用公钥进行验签会出现验签失败。 注:如是公钥证书方式,就需要传递支付宝公钥证书文件进行验签操作,如何获取支付宝公钥可点击【查看】。 2、验签报文存在问题 核实接收的验签报文是否完整,是否存在乱码,如果存在乱码,检查自己编码格式,通知的内容示例如下。 REQUEST URL: http://example.com/gateway.do(应用网关地址) REQUEST METHOD: POST(通知是请求方式) CONTENT:(以下为发送到应用网关上的内容) service=alipay.service.check sign=ntjOmXFGJMdfdMnrTL5rEp9QG8d0lDEoGg3ZHvqemHeI8BlQoEsFbhEn0IfQT+pvfJz5RCuE+3Qh1X7I4z5iTIiGjDBstc0xeuiAmtP9TrJZuw2jUAODFB9qOwBJLNcWlKHUGTU/db/qRsJQCj8EjoJvSi9MRM/xKv/XmduS/C4= sign_type=RSA2 charset=GBK biz_content= 注:通知数据默认是以GBK编码格式发送的,无法做修改,所以接收数据时需要以GBK编码格式去做接收,其他更多内容说明可点击【查看】。 3、验签代码方法有误并且未返回成功数据给支付宝 先确认是生活号应用上配置密钥时是选择公钥证书方式还是普通公钥方式: (1)如普通公钥方式,验签代码可参考【签名验签方法】内的生活号响应返回的数据验签说明。 (2)如公钥证书方式,验签代码可参考【公钥证书签名验签方法】内的生活号响应返回的数据验签说明。 注1:验签成功后还需要给支付宝返回相关的数据内容信息,并且普通公钥方式和公钥证书方式返回的内容信息还存在差异,详细可参考【激活开发者说明文档】内的返回验签成功消息说明。 注2:相关的生活号demo下载地址可点击【生活号demo下载】。

保持可爱mmm 2020-05-07 11:12:22 0 浏览量 回答数 0

回答

通常,字符äåö没问题,因为浏览器和Web应用程序的tomcat / java使用的默认字符集为latin1即。“理解”这些字符的ISO-8859-1。 要使UTF-8在Java + Tomcat + Linux / Windows + Mysql下工作,需要满足以下条件: 配置Tomcat的server.xml 必须配置连接器使用UTF-8编码url(GET请求)参数: 在上面的示例中,关键部分是URIEncoding =“ UTF-8”。这可以保证Tomcat将所有传入的GET参数处理为UTF-8编码。结果,当用户将以下内容写入浏览器的地址栏时: https://localhost:8443/ID/Users?action=search&name=ж 字符ж被当作UTF-8处理,并被编码为%D0%B6(通常在到达服务器之前由浏览器访问)。 POST请求不受此影响。 CharsetFilter 然后是时候强制Java Web应用程序以UTF-8编码方式处理所有请求和响应了。这要求我们定义一个字符集过滤器,如下所示: package fi.foo.filters; import javax.servlet.*; import java.io.IOException; public class CharsetFilter implements Filter { private String encoding; public void init(FilterConfig config) throws ServletException { encoding = config.getInitParameter("requestEncoding"); if (encoding == null) encoding = "UTF-8"; } public void doFilter(ServletRequest request, ServletResponse response, FilterChain next) throws IOException, ServletException { // Respect the client-specified character encoding // (see HTTP specification section 3.4.1) if (null == request.getCharacterEncoding()) { request.setCharacterEncoding(encoding); } // Set the default response content type and encoding response.setContentType("text/html; charset=UTF-8"); response.setCharacterEncoding("UTF-8"); next.doFilter(request, response); } public void destroy() { } } 此过滤器可确保如果浏览器未设置请求中使用的编码,则将其设置为UTF-8。 该过滤器完成的另一件事是设置默认响应编码,即。返回的html /所使用的编码。另一种方法是在应用程序的每个控制器中设置响应编码等。 该过滤器必须添加到web.xml或webapp的部署描述符中: CharsetFilter fi.foo.filters.CharsetFilter requestEncoding UTF-8 CharsetFilter /* 可以在tomcat Wiki(http://wiki.apache.org/tomcat/Tomcat/UTF-8)中找到有关创建此过滤器的说明。 JSP页面编码 在您的web.xml中,添加以下内容: *.jsp UTF-8 另外,Web应用程序的所有JSP页面都需要在其顶部具有以下内容: <%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"%> 如果使用具有不同JSP片段的某种布局,则所有这些都需要。 HTML元标记 JSP页面编码告诉JVM以正确的编码处理JSP页面中的字符。然后是时候告诉浏览器html页面的编码方式了: 这是通过在webapp生成的每个xhtml页面顶部执行以下操作来完成的: ... JDBC连接 使用数据库时,必须定义该连接使用UTF-8编码。可以在context.xml或以下定义了JDBC连接的地方完成: MySQL数据库和表 使用的数据库必须使用UTF-8编码。这是通过使用以下内容创建数据库来实现的: CREATE DATABASE `ID_development` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_swedish_ci */; 然后,所有表也都必须使用UTF-8: CREATE TABLE `Users` ( `id` int(10) unsigned NOT NULL auto_increment, `name` varchar(30) collate utf8_swedish_ci default NULL PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci ROW_FORMAT=DYNAMIC; 关键部分是CHARSET = utf8。 MySQL服务器配置 还必须配置MySQL serveri。通常,这是在Windows中通过修改my.ini -file和在Linux中通过配置my.cnf -file来完成的。在这些文件中,应该定义所有连接到服务器的客户端都使用utf8作为默认字符集,并且服务器使用的默认字符集也是utf8。 [client] port=3306 default-character-set=utf8 [mysql] default-character-set=utf8 MySQL的程序和功能 这些还需要定义字符集。例如: DELIMITER $$ DROP FUNCTION IF EXISTS `pathToNode` $$ CREATE FUNCTION `pathToNode` (ryhma_id INT) RETURNS TEXT CHARACTER SET utf8 READS SQL DATA BEGIN DECLARE path VARCHAR(255) CHARACTER SET utf8; SET path = NULL; ... RETURN path; END $$ DELIMITER ; GET请求:latin1和UTF-8 如果并且在tomcat的server.xml中定义了GET请求参数以UTF-8编码时,以下GET请求将得到正确处理: https://localhost:8443/ID/Users?action=search&name=Petteri https://localhost:8443/ID/Users?action=search&name=ж 由于latin1和UTF-8均以相同的方式编码ASCII字符,因此正确处理了字符串“ Petteri”。 拉丁语1完全不了解西里尔字母ж。由于指示Tomcat将请求参数处理为UTF-8,因此它将该字符正确编码为%D0%B6。 如果并且当指示浏览器读取UTF-8编码的页面(带有请求标头和html meta-tag)时,至少Firefox 2/3和此期间的其他浏览器都将字符本身编码为%D0%B6。 最终结果是,找到了所有名称为“ Petteri”的用户,还找到了所有名称为“ж”的用户。 但是äåö呢? HTTP规范定义默认情况下,URL编码为latin1。这导致firefox2,firefox3等对以下内容进行编码 https://localhost:8443/ID/Users?action=search&name=*Päivi* 进入编码版本 https://localhost:8443/ID/Users?action=search&name=*P%E4ivi* 在latin1中,字符ä编码为%E4。即使页面/请求/所有内容都定义为使用UTF-8。ä的UTF-8编码版本为%C3%A4 结果是,由于某些字符在latin1中编码,而另一些字符在UTF-8中编码,因此webapp完全不可能正确地处理GET请求中的请求参数。 注意:如果页面被定义为UTF-8,则POST请求确实可以工作,因为浏览器完全以UTF-8格式编码来自表单的所有请求参数。 读物 非常感谢以下作者为我的问题提供了答案: http://tagunov.tripod.com/i18n/i18n.html http://wiki.apache.org/tomcat/Tomcat/UTF-8 http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/ http://dev.mysql.com/doc/refman/5.0/en/charset-syntax.html http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-tomcat-jsp-etc.html http://cagan327.blogspot.com/2006/05/utf-8-encoding-fix-for-mysql-tomcat.html http://jeppesn.dk/utf-8.html http://www.nabble.com/request-parameters-mishandle-utf-8-encoding-td18720039.html http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html http://www.utf8-chartable.de/ 重要的提示 mysql支持使用3字节UTF-8字符的基本多语言平面。如果您需要超出此范围(某些字母需要超过3个字节的UTF-8字节),则需要使用一种VARBINARY列类型的样式或使用utf8mb4字符集(这需要MySQL 5.5.3或更高版本)。请注意,使用utf8MySQL中的字符集无法100%地工作。 Tomcat与Apache 还有一件事,如果您使用的是Apache + Tomcat + mod_JK连接器,则还需要进行以下更改: 将URIEncoding =“ UTF-8”添加到8009连接器的tomcat server.xml文件中,由mod_JK连接器使用。 转到你的apache文件夹即/etc/httpd/conf添加AddDefaultCharset utf-8在httpd.conf file。注意:首先检查它是否存在。如果存在,您可以使用此行对其进行更新。您也可以在底部添加此行。来源:stack overflow

保持可爱mmm 2020-05-10 17:04:59 0 浏览量 回答数 0

问题

如何操作DeleteRow

云栖大讲堂 2019-12-01 20:59:43 1054 浏览量 回答数 0

问题

如何使用表格存储的 API

云栖大讲堂 2019-12-01 20:58:54 1796 浏览量 回答数 0

问题

如何操作PutRow

云栖大讲堂 2019-12-01 20:59:40 1116 浏览量 回答数 0

问题

如何操作GetRow

云栖大讲堂 2019-12-01 20:59:37 1151 浏览量 回答数 0

问题

关于Object操作之如何实现CopyObject?

青衫无名 2019-12-01 21:50:01 3315 浏览量 回答数 2

问题

如何操作UpdateRow

云栖大讲堂 2019-12-01 20:59:41 890 浏览量 回答数 0

回答

问题定义 A -> B 发起TCP请求,A端为请求侧,B端为服务侧TCP 三次握手已完成TCP 三次握手后双方没有任何数据交互B 在无预警情况下掉线(类似意外掉电重启状态) 问题答案 A侧的TCP链路状态在未发送任何数据的情况下与等待的时间相关,如果在多个超时值范围以内那么状态为established;如果触发了某一个超时的情况那么视情况的不同会有不同的改变。 一般情况下不管是KeepAlive超时还是内核超时,只要出现超时,那么必然会抛出异常,只是这个异常截获的时机会因编码方式的差异而有所不同。(同步异步IO,以及有无使用select、poll、epoll等IO多路复用机制) 原因与相关细节 大前提 基于IP网络的无状态特征,A侧系统不会在无动作情况下收到任何通知获知到B侧掉线的情况(除非AB是直连状态,那么A可以获知到自己网卡掉线的异常) 在此大前提的基础上,会因为链路环境、SOCKET设定、以及内核相关配置的不同,A侧会在不同的时机获知到B侧无响应的结果,但总归是以异常的形式获得这个结果。 <关于内核对待无数据传递SOCKET的方式> 操作系统有一堆时间超级长的兜底用timeout参数,用于在不同的时候给TCP栈一个异常退出的机会,避免无效连接过多而耗尽系统资源 其中,TCP KeepAive 特性能让应用层配置一个远小于内核timeout参数的值,用于在这一堆时间超长的兜底参数生效之前,判断链路是否为有效状态。 <关于超时的各个节点> 以下仅讨论三次握手成功之后的兜底情况 TCP链路在建立之后,内核会初始化一个由<nf_conntrack_tcp_timeout_established>参数控制的计时器(这个计时器在Ubuntu 18.04里面长达5天),以防止在未开启TCP KeepAlive的情况下连接因各种原因导致的长时间无动作而过度消耗系统资源,这个计时器会在每次TCP链路活动后重置 TCP正常传输过程中,每一次数据发送之后,必然伴随对端的ACK确认信息。如果对端因为各种原因失去反应(网络链路中断、意外掉电等)这个ACK将永远不会到来,内核在每次发送之后都会重置一个由<nf_conntrack_tcp_timeout_unacknowledged>参数控制的计时器,以防止对端以外断网导致的资源过度消耗。(这个计时器在Ubuntu 18.04里面是300秒/5分钟) 以上两个计时器作为keepalive参数未指定情况下的兜底参数,为内核自保特性,所以事件都很长,建议实际开发与运维中用更为合理的参数覆盖这些数值 <关于链路异常后发生的操作> A侧在超时退出之后一般会发送一个RST包用于告知对端重置链路,并给应用层一个异常的状态信息,视乎同步IO与异步IO的差异,这个异常获知的时机会有所不同。 B侧重启之后,因为不存有之前A-B之间建立链路相关的信息,这时候收到任何A侧来的数据都会以RST作为响应,以告知A侧链路发生异常 RST的设计用意在于链路发生意料之外的故障时告知链路上的各方释放资源(一般指的是NAT网关与收发两端);FIN的设计是用于在链路正常情况下的正常单向终止与结束。二者不可混淆。 关于阻塞 应用层到底层网卡发送的过程中,数据包会经历多个缓冲区,也会经历一到多次的分片操作,阻塞这一结果的发生是具有从底向上传递的特性。 这一过程中有一个需要强调的关键点:socket.send这个操作只是把数据发送到了内核缓冲区,只要数据量不大那么这个调用必然是在拷贝完之后立即返回的。而数据量大的时候,必然会产生阻塞。 在TCP传输中,决定阻塞与否的最终节点,是TCP的可靠传输特性。此特性决定了必须要有ACK数据包回复响应正确接收的数据段范围,内核才会把对应的数据从TCP发送缓冲区中移除,腾出空间让新的数据可以写入进来。 这个过程意味着,只要应用层发送了大于内核缓冲区可容容纳的数据量,那么必然会在应用层出现阻塞,等待ACK的到来,然后把新数据压入缓冲队列,循环往复,直到数据发送完毕。

九旬 2020-05-24 22:22:41 0 浏览量 回答数 0

问题

关于Object操作之如何实现PostObject?

青衫无名 2019-12-01 21:50:18 2821 浏览量 回答数 0

问题

关于MultipartUpload的操作之ListMultipartUploads?

青衫无名 2019-12-01 21:54:38 1526 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 CopyObject接口用于拷贝一个在OSS上已经存在的object成另外一个object。 该接口可以发送一个PUT请求给OSS,并在PUT请求头中添加元素x-oss-copy-source来指定拷贝源。OSS会自动判断出这是一个Copy操作,并直接在服务器端执行该操作。如果拷贝成功,则返回新的object信息给用户。 该操作适用于拷贝小于1GB的文件,当拷贝一个大于1GB的文件时,必须使用Multipart Upload操作,具体见Upload Part Copy。 Copy操作的源Bucket和目标Bucket必须是同一个Region,不同Region的Bucket不能执行Copy Object操作。 请求语法 PUT /DestObjectName HTTP/1.1 Host: DestBucketName.oss-cn-hangzhou.aliyuncs.com Date: GMT Date Authorization: SignatureValue x-oss-copy-source: /SourceBucketName/SourceObjectName 请求Header 名称 类型 描述 x-oss-copy-source 字符串 复制源地址(必须有可读权限) 默认值:无 x-oss-copy-source-if-match 字符串 如果源Object的ETag值和用户提供的ETag相等,则执行拷贝操作,并返回200;否则返回412 HTTP错误码(预处理失败)。 默认值:无 x-oss-copy-source-if-none-match 字符串 如果源Object的ETag值和用户提供的ETag不相等,则执行拷贝操作,并返回200;否则返回304 HTTP错误码(预处理失败)。 默认值:无 x-oss-copy-source-if-unmodified-since 字符串 如果传入参数中的时间等于或者晚于文件实际修改时间,则正常传输文件,并返回200 OK;否则返回412 precondition failed错误。 默认值:无 x-oss-copy-source-if-modified-since 字符串 如果源Object自从用户指定的时间以后被修改过,则执行拷贝操作;否则返回304 HTTP错误码(预处理失败)。 默认值:无 x-oss-metadata-directive 字符串 有效值为COPY和REPLACE。如果该值设为COPY,则新的Object的meta都从源Object复制过来;如果设为REPLACE,则忽视所有源Object的meta值,而采用用户这次请求中指定的meta值;其他值则返回400 HTTP错误码。注意该值为COPY时,源Object的x-oss-server-side-encryption的meta值不会进行拷贝。 取值: COPY (默认值) REPLACE x-oss-server-side-encryption 字符串 指定oss创建目标object时的服务器端熵编码加密算法 取值:AES256 或 KMS 说明 您需要购买KMS套件,才可以使用KMS加密算法,否则会报KmsServiceNotEnabled错误码。 x-oss-object-acl 字符串 指定oss创建object时的访问权限。 取值:public-read,private,public-read-write 响应元素(Response Elements) 表 1. 响应元素 名称 类型 描述 CopyObjectResult 字符串 Copy Object的结果。 默认值:无 ETag 字符串 新Object的ETag值。 父元素:CopyObjectResult LastModified 字符串 新Object最后更新时间。 父元素:CopyObjectResult 细节分析 可以通过拷贝操作来实现修改已有Object的meta信息。 如果拷贝操作的源Object地址和目标Object地址相同,则无论x-oss-metadata-directive为何值,都会直接替换源Object的meta信息。 OSS支持拷贝操作的四个预判断Header任意个同时出现,相应逻辑参见Get Object操作的细节分析。 拷贝操作需要请求者对源Object有读权限。 源Object和目标Object必须属于同一个数据中心,否则返回403 AccessDenied,错误信息为:Target object does not reside in the same data center as source object。 拷贝操作的计费统计会对源Object所在的Bucket增加一次Get请求次数,并对目标Object所在的Bucket增加一次Put请求次数,以及相应的新增存储空间。 拷贝操作涉及到的请求头,都是以“x-oss-”开头的,所以要加入签名字符串中。 若在拷贝操作中指定了x-oss-server-side-encryption请求头,并且请求值合法(为AES256),则无论源Object是否进行过服务器端加密编码,拷贝之后的目标Object都会进行服务器端加密编码。并且拷贝操作的响应头中会包含x-oss-server-side-encryption,值被设置成目标Object的加密算法。在这个目标Object被下载时,响应头中也会包含x-oss-server-side-encryption,值被设置成该Object的加密算法;若拷贝操作中未指定x-oss-server-side-encryption请求头,则无论源Object是否进行过服务器端加密编码,拷贝之后的目标Object都是未进行过服务器端加密编码加密的数据。 拷贝操作中x-oss-metadata-directive请求头为COPY(默认值)时,并不拷贝源Object的x-oss-server-side-encryption值,即目标Object是否进行服务器端加密编码只根据COPY操作是否指定了x-oss-server-side-encryption请求头来决定。 若在拷贝操作中指定了x-oss-server-side-encryption请求头,并且请求值非AES256,则返回400和相应的错误提示:InvalidEncryptionAlgorithmError。 如果拷贝的文件大小大于1GB,会返回400和错误提示:EntityTooLarge。 该操作不能拷贝通过Append追加上传方式产生的object。 如果文件类型为符号链接,只拷贝符号链接。 示例 请求示例: PUT /copy_oss.jpg HTTP/1.1 Host: oss-example.oss-cn-hangzhou.aliyuncs.com Date: Fri, 24 Feb 2012 07:18:48 GMT x-oss-copy-source: /oss-example/oss.jpg Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:gmnwPKuu20LQEjd+iPkL259A+n0= 返回示例: HTTP/1.1 200 OK x-oss-request-id: 559CC9BDC755F95A64485981 Content-Type: application/xml Content-Length: 193 Connection: keep-alive Date: Fri, 24 Feb 2012 07:18:48 GMT Server: AliyunOSS <?xml version="1.0" encoding="UTF-8"?> <CopyObjectResult xmlns=”http://doc.oss-cn-hangzhou.aliyuncs.com”> <LastModified>Fri, 24 Feb 2012 07:18:48 GMT</LastModified> <ETag>"5B3C1A2E053D763E1B002CC607C5A0FE"</ETag> </CopyObjectResult>

2019-12-01 23:13:50 0 浏览量 回答数 0

问题

Nginx性能为什么如此吊

小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

回答

详细解答可以参考官方帮助文档 PostObject使用HTML表单上传文件到指定bucket。 Post作为Put的替代品,使得基于浏览器上传文件到bucket成为可能。Post Object的消息实体通过多重表单格式(multipart/form-data)编码,在Put Object操作中参数通过HTTP请求头传递,在Post操作中参数则作为消息实体中的表单域传递。 Post object 请求语法 POST / HTTP/1.1 Host: BucketName.oss-cn-hangzhou.aliyuncs.com User-Agent: browser_data Content-Length:ContentLength Content-Type: multipart/form-data; boundary=9431149156168 --9431149156168 Content-Disposition: form-data; name="key" key --9431149156168 Content-Disposition: form-data; name="success_action_redirect" success_redirect --9431149156168 Content-Disposition: form-data; name="Content-Disposition" attachment;filename=oss_download.jpg --9431149156168 Content-Disposition: form-data; name="x-oss-meta-uuid" myuuid --9431149156168 Content-Disposition: form-data; name="x-oss-meta-tag" mytag --9431149156168 Content-Disposition: form-data; name="OSSAccessKeyId" access-key-id --9431149156168 Content-Disposition: form-data; name="policy" encoded_policy --9431149156168 Content-Disposition: form-data; name="Signature" signature --9431149156168 Content-Disposition: form-data; name="file"; filename="MyFilename.jpg" Content-Type: image/jpeg file_content --9431149156168 Content-Disposition: form-data; name="submit" Upload to OSS --9431149156168-- 表单域 名称 类型 描述 必须 OSSAccessKeyId 字符串 Bucket 拥有者的Access Key Id。 默认值:无 限制:当bucket非public-read-write或者提供了policy(或Signature)表单域时,必须提供该表单域。 有条件的 policy 字符串 policy规定了请求的表单域的合法性。不包含policy表单域的请求被认为是匿名请求,并且只能访问public-read-write的bucket。更详细描述请参考下文 Post Policy。 默认值:无 限制:当bucket非public-read-write或者提供了OSSAccessKeyId(或Signature)表单域时,必须提供该表单域。 有条件的 Signature 字符串 根据Access Key Secret和policy计算的签名信息,OSS验证该签名信息从而验证该Post请求的合法性。更详细描述请参考下文 Post Signature。 默认值:无 限制:当bucket非public-read-write或者提供了OSSAccessKeyId(或policy)表单域时,必须提供该表单域。 有条件的 Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires 字符串 REST请求头,更多的信息见Put Object。 默认值:无 可选 file 字符串 文件或文本内容,必须是表单中的最后一个域。浏览器会自动根据文件类型来设置Content-Type,会覆盖用户的设置。 OSS一次只能上传一个文件。 默认值:无 必须 key 字符串 上传文件的object名称。 如果名称包含路径,如a/b/c/b.jpg, 则OSS会自动创建相应的文件夹。 默认值:无 必须 success_action_redirect 字符串 上传成功后客户端跳转到的URL,如果未指定该表单域,返回结果由success_action_status表单域指定。如果上传失败,OSS返回错误码,并不进行跳转。 默认值:无 可选 success_action_status 字符串 未指定success_action_redirect表单域时,该表单域指定了上传成功后返回给客户端的状态码。 接受值为200, 201, 204(默认)。 如果该域的值为200或者204,OSS返回一个空文档和相应的状态码。 如果该域的值设置为201,OSS返回一个XML文件和201状态码。 如果其值未设置或者设置成一个非法值,OSS返回一个空文档和204状态码。 默认值:无 x-oss-meta-* 字符串 用户指定的user meta值。 OSS不会检查或者使用该值。 默认值:无 可选 x-oss-server-side-encryption 字符串 指定OSS创建object时的服务器端加密编码算法。 合法值:AES256 可选 x-oss-object-acl 字符串 指定oss创建object时的访问权限。 合法值:public-read,private,public-read-write 可选 x-oss-security-token 字符串 若本次访问是使用STS临时授权方式,则需要指定该项为SecurityToken的值,同时OSSAccessKeyId需要使用与之配对的临时AccessKeyId,计算签名时,与使用普通AccessKeyId签名方式一致。 默认值:无 可选 响应Header 名称 类型 描述 x-oss-server-side-encryption 字符串 如果请求指定了x-oss-server-side-encryption熵编码,则响应Header中包含了该头部,指明了所使用的加密算法。 响应元素(Response Elements) 名称 类型 描述 PostResponse 容器 保持Post请求结果的容器。 子节点:Bucket, ETag, Key, Location Bucket 字符串 Bucket名称。 父节点:PostResponse ETag 字符串 ETag (entity tag) 在每个Object生成的时候被创建,Post请求创建的Object,ETag值是该Object内容的uuid,可以用于检查该Object内容是否发生变化。 父节点:PostResponse Location 字符串 新创建Object的URL。 父节点:PostResponse 细节分析 进行Post操作要求对bucket有写权限,如果bucket为public-read-write,可以不上传签名信息,否则要求对该操作进行签名验证。与Put操作不同,Post操作使用AccessKeySecret对policy进行签名计算出签名字符串作为Signature表单域的值,OSS会验证该值从而判断签名的合法性。 无论bucket是否为public-read-write,一旦上传OSSAccessKeyId, policy, Signature表单域中的任意一个,则另两个表单域为必选项,缺失时OSS会返回错误码:InvalidArgument。 post操作提交表单编码必须为“multipart/form-data”,即header中Content-Type为multipart/form-data;boundary=xxxxxx 这样的形式,boundary为边界字符串。 提交表单的URL为bucket域名即可,不需要在URL中指定object。即请求行是POST / HTTP/1.1,不能写成POST /ObjectName HTTP/1.1。 policy规定了该次Post请求中表单域的合法值,OSS会根据policy判断请求的合法性,如果不合法会返回错误码:AccessDenied。在检查policy合法性时,policy中不涉及的表单域不进行检查。 表单和policy必须使用UTF-8编码,policy为经过UTF-8编码和base64编码的JSON。 Post请求中可以包含额外的表单域,OSS会根据policy对这些表单域检查合法性。 如果用户上传了Content-MD5请求头,OSS会计算body的Content-MD5并检查一致性,如果不一致,将返回InvalidDigest错误码。 如果POST请求中包含Header签名信息或URL签名信息,OSS不会对它们做检查。 如果请求中携带以x-oss-meta-为前缀的表单域,则视为user meta,比如x-oss-meta-location。一个Object可以有多个类似的参数,但所有的user meta总大小不能超过8k。 Post请求的body总长度不允许超过5G。若文件长度过大,会返回错误码:EntityTooLarge。 如果上传指定了x-oss-server-side-encryption Header请求域,则必须设置其值为AES256,否则会返回400和错误码:InvalidEncryptionAlgorithmError。指定该Header后,在响应头中也会返回该Header,OSS会对上传的Object进行加密编码存储,当这个Object被下载时,响应头中会包含x-oss-server-side-encryption,值被设置成该Object的加密算法。 表单域为大小写不敏感的,但是表单域的值为大小写敏感的。 示例 请求示例:POST / HTTP/1.1 Host: oss-example.oss-cn-hangzhou.aliyuncs.com Content-Length: 344606 Content-Type: multipart/form-data; boundary=9431149156168 --9431149156168 Content-Disposition: form-data; name="key" /user/a/objectName.txt --9431149156168 Content-Disposition: form-data; name="success_action_status" 200 --9431149156168 Content-Disposition: form-data; name="Content-Disposition" content_disposition --9431149156168 Content-Disposition: form-data; name="x-oss-meta-uuid" uuid --9431149156168 Content-Disposition: form-data; name="x-oss-meta-tag" metadata --9431149156168 Content-Disposition: form-data; name="OSSAccessKeyId" 44CF9590006BF252F707 --9431149156168 Content-Disposition: form-data; name="policy" eyJleHBpcmF0aW9uIjoiMjAxMy0xMi0wMVQxMjowMDowMFoiLCJjb25kaXRpb25zIjpbWyJjb250ZW50LWxlbmd0aC1yYW5nZSIsIDAsIDEwNDg1NzYwXSx7ImJ1Y2tldCI6ImFoYWhhIn0sIHsiQSI6ICJhIn0seyJrZXkiOiAiQUJDIn1dfQ== --9431149156168 Content-Disposition: form-data; name="Signature" kZoYNv66bsmc10+dcGKw5x2PRrk= --9431149156168 Content-Disposition: form-data; name="file"; filename="MyFilename.txt" Content-Type: text/plain abcdefg --9431149156168 Content-Disposition: form-data; name="submit" Upload to OSS --9431149156168-- 返回示例:HTTP/1.1 200 OK x-oss-request-id: 61d2042d-1b68-6708-5906-33d81921362e Date: Fri, 24 Feb 2014 06:03:28 GMT ETag: 5B3C1A2E053D763E1B002CC607C5A0FE Connection: keep-alive Content-Length: 0 Server: AliyunOSS Post Policy Post请求的policy表单域用于验证请求的合法性。 policy为一段经过UTF-8和base64编码的JSON文本,声明了Post请求必须满足的条件。虽然对于public-read-write的bucket上传时,post表单域为可选项,我们强烈建议使用该域来限制Post请求。 policy示例 { "expiration": "2014-12-01T12:00:00.000Z", "conditions": [ {"bucket": "johnsmith" }, ["starts-with", "$key", "user/eric/"] ] } Post policy中必须包含expiration和condtions。 Expiration Expiration项指定了policy的过期时间,以ISO8601 GMT时间表示。例如”2014-12-01T12:00:00.000Z”指定了Post请求必须发生在2014年12月1日12点之前。 Conditions Conditions是一个列表,可以用于指定Post请求的表单域的合法值。注意:表单域对应的值在检查policy之后进行扩展,因此,policy中设置的表单域的合法值应当对应于扩展之前的表单域的值。Policy中支持的conditions项见下表: 名称 描述 content-length-range 上传文件的最小和最大允许大小。 该condition支持contion-length-range匹配方式。 Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires HTTP请求头。 该condition支持精确匹配和starts-with匹配方式。 key 上传文件的object名称。 该condition支持精确匹配和starts-with匹配方式。 success_action_redirect 上传成功后的跳转URL地址。 该condition支持精确匹配和starts-with匹配方式。 success_action_status 未指定success_action_redirect时,上传成功后的返回状态码。 该condition支持精确匹配和starts-with匹配方式。 x-oss-meta-* 用户指定的user meta。 该condition支持精确匹配和starts-with匹配方式。 如果Post请求中包含其他的表单域,可以将这些额外的表单域加入到policy的conditions中,conditions不涉及的表单域将不会进行合法性检查。 Conditions匹配方式 Conditions匹配方式 描述 精确匹配 表单域的值必须精确匹配conditions中声明的值。如指定key表单域的值必须为a: {“key”: “a”} 同样可以写为: [“eq”, “$key”, “a”] Starts With 表单域的值必须以指定值开始。例如指定key的值必须以/user/user1开始: [“starts-with”, “$key”, “/user/user1”] 指定文件大小 指定所允许上传的文件最大大小和最小大小,例如允许的文件大小为1到10字节: [“content-length-range”, 1, 10] 转义字符 于在 Post policy 中 $ 表示变量,所以如果要描述 $,需要使用转义字符\$。除此之外,JSON 将对一些字符进行转义。下图描述了 Post policy 的 JSON 中需要进行转义的字符。 转义字符 描述 \/ 斜杠 \ 反斜杠 \” 双引号 \$ 美元符 \b 空格 \f 换页 \n 换行 \r 回车 \t 水平制表符 \uxxxx Unicode 字符 Post Signature 对于验证的Post请求,HTML表单中必须包含policy和Signature信息。policy控制请求中那些值是允许的。计算Signature的具体流程为: 创建一个 UTF-8 编码的 policy。 将 policy 进行 base64 编码,其值即为 policy 表单域该填入的值,将该值作为将要签名的字符串。 使用 AccessKeySecret 对要签名的字符串进行签名,签名方法与Head中签名的计算方法相同(将要签名的字符串替换为 policy 即可),请参见在Header中包含签名。 示例 Demo Web 端表单直传 OSS 示例 Demo,请参见JavaScript客户端签名直传。

2019-12-01 23:13:50 0 浏览量 回答数 0

问题

IIS7.5安装配置UrlScan3.1应用防火墙

虎笑 2019-12-01 21:00:19 11275 浏览量 回答数 2

回答

木心的《从前慢》里说: 记得早先少年时 大家诚诚恳恳 说一句 是一句 …… 从前的日色变得慢 车,马,邮件都慢 一生只够爱一个人 从前的锁也好看 钥匙精美有样子 你锁了 人家就懂了 木心怀念着过去那个通过邮件传递信息的简单时代。 当下的网络时代虽然瞬息万变,但传递信息也是一样的“说一句,是一句”,“你 锁了,人家就懂了”。 小程序经常需要往服务器传递数据或者从服务器拉取信息。 当用户通过小程序加载服务器传来的信息时,整个网络过程如下: 1. 用户通过小程序向服务器发出 GET 请求, 2. 服务器发送一个响应,响应信息包含一个数据文件。 上面的流程也许过于简化,其实用户与服务器之间不可能面对面直接通话,因为它 们相隔不是很近,甚至服务器是在浏览器的千里之外,而客户端浏览器不可能直通 服务器。 每一次的网络请求,小程序传递给服务器的信息,中间经过多重的信息转达。同理 服务器回应小程序的响应也是同样的路径。 通俗点说,就是传纸条的原理。写字条的同学需要把字条递给旁边第一个同学,然 后第二个同学递给第三个同学,以此类推,一直传递到最后的信息接收者。 让我们看看,在传递字条的过程中,如果信息发出者想要给信息最末尾的接受者告 白,会发生什么呢? 在HTTP 状态下,传递者都可以打开字条,查看里面的内容。而且发送信息者无法知道传输路径,一旦发生信息窃取,甚至不知道是谁窃取的。 还是就是当信息落入心怀不轨的人手中,或者篡改信息内容,其后果不可设想。比如,把“你喜欢我吗?”篡改成“你不喜欢我吗?”。 为了避免这些情况发生,HTTP 安全版本应运而生,即HTTPS。通过HTTPS,传送的每次信息都被加上一个锁。 该锁配套的公钥和密钥仅小程序和服务器知道,其他传递者无法获取。因此,无论客户端发送的信息经过多个路由器,他人都无法读取信息内容。客户端发送初始信息到服务器时,在信息内容中包含服务器的名称(在名为“服务器名称指示”的字段中)。而服务器运行商可以在同一台计算机上运行多个站点, 因此运行商可以跟踪到客户端的访问轨迹。虽然初始的信息已设置了加密,但是初始请求是仍未加密的。这就是通过小程序my.request 安全传递告白信息的故事。本节将介绍如何使用my.request API 实现网络请求,并介绍一些使用注意事项。版本要求:基础库1.11.0 或更高版本;支付宝客户端10.1.32 或更高版本,若版本较低,建议做兼容处理。 my.request 目前只支持HTTPS 协议的请求。 使用说明:  请预先在 支付宝小程序管理中心 > 小程序详情 > 设置 > 开发设置 > 服务器域名白名单 中配置域名白名单。小程序在以下 API 调用时只能与白名单中的域名进行通讯:HTTP 请 求(my.request)、上传文件(my.uploadFile)、下载文件(my.downloadFile)和 WebSocket(my.connectSocket)。  添加服务器域名白名单后,需要重新打包上传生成体验版,服务器域名才会生效。  在 IDE 上进行调试时,请使用真机预览调试。  支付宝客户端已不再维护 my.httpRequest,建议使用 my.request。另外,钉钉客户端尚 不支持 my.request。若在钉钉客户端开发小程序,则需要使用 my.httpRequest。 扫码体验 重要:  小程序开发过程中,可在开发工具内 详情 > 域名信息 > 忽略 httpRequest 域名合法性 检查 中选择是否忽略域名合法性检查,如果选择忽略,则在模拟器、预览以及真机调试场 景不会校验域名合法性,但小程序上线前必须确保通讯域名在白名单内,否则在正式版本无 法调用。  my.request 的请求头默认值为 {'content-type': 'application/json'},而不是{'contenttype': 'application/x-www-form-urlencoded'}。此外,请求头对象里面的 key 和 value 必须是 String 类型。 示例代码 my.request({ url: 'https://httpbin.org/post', method: 'POST', data: { from: '支付宝', production: 'AlipayJSAPI', }, dataType: 'json', success: function(res) { my.alert({content: 'success'}); }, fail: function(res) { my.alert({content: 'fail'}); }, complete: function(res) { my.hideLoading(); my.alert({content: 'complete'}); } }); // dataType 为 base64 示例 my.request({ url: 'https://gw.alipayobjects.com/mdn/miniapp_de/afts/img/A*G1kWSJbe2zEAAAAA AAAAAABjARQnAQ', method: 'GET', dataType: 'base64', success: (resp) => { console.log('resp data length', resp.data.length); console.log('resp data', resp.data); // 返回格式类似于: data:image/png;base64,iVBORw0KG... }, fail: (err) => { console.log('error', err); }, }) 入参 Object 类型,属性如下: 属性 类型 必填 描述 url String 是 目标服务器 URL。 headers Object 否 设置请求的 HTTP 头对象,默认 {'content-type': 'application/json'},该对象里面 的 key 和 value 必须是 String 类型。 method String 否 默认 GET,目前支持 GET/POST/PUT/DELETE。 data Object 否 详见 data 参数说明。 timeout Number 否 超时时间,单位 ms,默认 30000。 dataType String 否 期望返回的数据格式,默认 JSON,支持 JSON、text、 base64、arraybuffer (10.1.70 版本开始支持) 。 success Function 否 调用成功的回调函数。 fail Function 否 调用失败的回调函数。 complete Function 否 调用结束的回调函数(调用成功、 失败都会执行)。 data 参数说明 传给服务器的数据最终会是 String 类型,如果 data 不是 String 类型,会被 转换成 String 。转换规则如下:  若方法为 GET,会将数据转换成 query string: encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=enc odeURIComponent(v)...  若方法为 POST 且 headers['content-type'] 为 application/json ,会对数据进行 JSON 序列化  若方法为 POST 且 headers['content-type'] 为 application/x-www-formurlencoded ,会将数据转换成 query string: encodeURIComponent(k)=encodeURIComponent(v)&encodeURIComponent(k)=enc odeURIComponent(v)... success 回调函数 入参为 Object 类型,属性如下: 属性 类型 描述 data String 响应数据,格式取决于请求时的 dataType 参数, 如果 dataType 值为 base64 时,返回的是符合 data URI scheme 规范的内容字符串。 status Number 响应码。 headers Object 响应头。 返回值 RequestTask 网络请求任务对象。调用 my.request 后返回的请求对象。 RequestTask.abort() 中断请求任务。 示例代码 const task = my.request({url: 'https://httpbin.org/post'}) task.abort(); “抱歉,不是我的菜”:小程序扫码点餐化解尴 尬 月上柳梢头,人约黄昏后。 周五到了,小心翼翼约她出来吃晚饭,她欣然应约。 餐厅位于徐汇区闹中取静的华山路,法式梧桐的点缀让餐厅更显典雅,也更富有异 国情调。踏入餐厅,灯光是橘色的,餐具是蓝的,桌椅也是蓝的,让人恍惚之间有 到了爱琴海边的错觉,唯美的装修风格、充满欧洲风味的精致美食,处处洋溢着地 中海风情,真浪漫啊。 她翩翩而至,裙裾飞扬。 见到她我脸红了。我紧张地问她要吃些什么,又手忙脚乱地叫来服务员点完了菜, 脸上冒出了小汗珠。 窗外的小雨滴滴答答,窗内的我们显得格外安静。 我鼓起勇气,打破沉默,小声问道:“你……你对我印象如何?” “抱歉,不是我的菜……” 此刻,我如同五雷轰顶,只觉天旋地转,眼前华光溢彩的餐厅瞬间变得黯淡了。 “你是不是点错菜了?还是上错菜了呢?”她指着桌上的法式田螺和奶油蘑菇汤, 瞪大了眼睛问我。旁边站着满脸疑惑的上菜员。 如何化解点错菜的尴尬呢?这时就需要使用支付宝小程序扫码点餐的功能了。 为了让用户减少输入,我们可以把复杂的信息编码成一个二维码,利用 my.scan API 调起支付宝扫一扫,用户扫码之后,my.scan 的 success 回调会收到这个 二维码所对应的字符串信息。 例如餐厅点餐的小程序,我们给餐厅中每个餐桌编号 1-100 号,把这个数字编码 到二维码中,扫码获得编号之后,就可以知道是哪一桌点的菜,大大提高点餐体验 和效率。 //page.js Page({ // 点击“扫码订餐”的按钮,触发 tapScan 回调 tapScan: function() { // 调用 my.login 获取微信登录凭证 my.scanCode({ success: function(res) { var num = res.result // 获取到的 num 就是餐桌的编号 } }) } }) 还有很多场景可以结合支付宝 App 扫码能力做到很好的体验,例如通过扫商品 上的一维码做一个商品展示的小程序;通过扫共享单车上的二维码去开启单车。我 们可以多思考如何利用这个扫码能力去替代一些繁琐的输入操作,让我们的小程序 变得更加便捷。 示例代码 // API-DEMO page/API/scan-code/scan-code.json { "defaultTitle": "Scan" <!-- API-DEMO page/API/scan-code/scan-code.axml--> <view class="page"> <view class="page-section"> <form onSubmit="scanCode"> <view> <button type="primary" onTap="scan">扫码</button> </view> </form> </view> </view> // API-DEMO page/API/scan-code/scan-code.js Page({ scan() { my.scan({ type: 'qr', success: (res) => { my.alert({ title: res.code }); }, }); } }) 入参 Object 类型,属性如下: 内容来源:https://developer.aliyun.com/article/756818?spm=a2c6h.12873581.0.dArticle756818.26162b70Su1GZy&groupCode=tech_library

KaFei 2020-04-27 15:46:55 0 浏览量 回答数 0

回答

一、说明 只有先激活开发者模式才可以进行测试生活号相关功能 。 1、生活号激活开发者模式demo:【点击查看】 。 2、生活号官方激活文档:【点击查看】。 3、生活号支付宝后台操作地址(无需开发接口):【点击访问】。 二、普通公钥方式激活流程 1、首先点击【开发者中心】>选择生活号类型>点击生活号类型下的生活号应用进入生活号详情页>点击应用信息这一栏,到如下图页面。 注:如未创建过生活号应用,可参考【如何创建应用】说明进行创建生活号应用,再进行配置操作。 2、点击应用网关这一栏上的设置按钮,在弹出的页面上加签模式选择公钥,并且配置应用公钥内容,再保存设置,如下图所示。 注:商户应用公钥如何生成可参考【如何生成RSA2密钥】说明内容。 3、再次在当前页面点击应用网关这一栏的验证应用网关按钮,到如下图页面。 4、通过下载【生活号官方demo】,在demo上配置相关的支付宝的appid、商户公钥、商户私钥、支付宝公钥等数据(以java截图为例)。 5、demo上的数据配置成功后,(以java版demo为例)把demo放在自己的服务器上,将demo程序中GatewayServlet的访问路径写入步骤3中的应用网关输入框中(如该demo服务的外网地址为http://test.fuwuchuang.com,此时应用网关为http://test.fuwuchuang.com/fuwuchuang_demo/gateway.do)。 注1:gateway.do文件页面在php版demo对应的是Gateway.php这个页面,在.net版demo上对应的是Gateway.asp页面。 注2:如接收页面是自行编写的,必须能外网访问,并且能以post方式去接收GBK编码格式的数据内容,并且需要在接收页面进行做验签处理,验签成功后需符合给支付宝信息,详细可参考demo上的接收写法或者参考【激活开发者文档说明】,应用网关拼接方式是:外网地址+项目名称+能接收数据的文件页面。 6、把拼接好的地址填写在步骤3中页面上的应用网关这一栏上,点击确认按钮,如代码和配置的数据无误的情况下,就会显示激活成功。 三、公钥证书方式激活流程 1、首先点击【开发者中心】>选择生活号类型>点击生活号类型下的生活号应用进入生活号详情页>点击应用信息这一栏,到如下图页面。 帖子图片155.png 注:如未创建过生活号应用,可参考【如何创建应用】说明进行创建生活号应用,再进行配置操作。 2、点击应用网关这一栏上的设置按钮,在弹出的页面上加签模式选择公钥证书,并且配置应用公钥内容,再保存设置,如下图所示。 帖子图片156.png 注:公钥证书文件如何生成可参考【如何生成公钥证书】说明内容。 3、再次在当前页面点击应用网关这一栏的验证应用网关按钮,到如下图所示页面。 4、通过下载【生活号官方demo】,(以java的demo说明为例)参考demo中的GatewayServlet的文件上的代码去编写能以post方式去接收GBK编码格式的数据内容页面,并且需在该页面写证书验签的代码逻辑,详细证书验签的逻辑说明可参考【公钥证书签名验签方法】内的生活号响应返回的数据验签说明。 注1:生活号官方demo上封装的sdk版本过低会存在没有公钥证书的验签方法,需下载【服务端sdk】进行更新替换。 注2:支付宝网关会向开发者网关发送的验证消息内容请求示例如下。 REQUEST URL: http://example.com/gateway.do REQUEST METHOD: POST CONTENT:(以下数据为参与验签时传递的待签名字符串内容,验签时需对数据进行排序处理) service=alipay.service.check sign=ntjOmXFGJMdfdMnrTL5rEp9QG8d0lDEoGg3ZHvqemHeI8BlQoEsFbhEn0IfQT+pvfJz5RCuE+3Qh1X7I4z5iTIiGjDBstc0xeuiAmtP9TrJZuw2jUAODFB9qOwBJLNcWlKHUGTU/db/qRsJQCj8EjoJvSi9MRM/xKv/XmduS/C4= sign_type=RSA2 charset=GBK biz_content= 5、验签成功后需返回验签成功消息给支付宝,内容示例如下。 true 6cd4ee7e4f31c1adba2380cc65da4a3a DXr8LVfHytoZ3RR0K95pzGtA3d9LdpjIjLEis2BDIPQisPwS+FMFxZt9NCMt531EeDj/nbzoIAz8Or7PuqxNfSzNI8qnhirm/Hvr8uedXX9JiQxHu8q3Rw2lJWD8cqQzgf3xwV/+wbN8yuI7s8xjo6odq6NCqrAIu7E0DDfZyKo= RSA2 app_cert_sn值是通过解析应用公钥证书文件中签发机构名称(name)以及内置序列号(serialNumber),将二者拼接后的字符串计算MD5值获取,可参考开放平台SDK源码中AlipaySignature.getCertSN实现,如下所示。 /** * 获取证书序列号 * @param certPath X.509证书文件路径 * @return 返回证书序列号 * @throws AlipayApiException */ public static String getCertSN(String certPath) sign值是对 节点内的内容作待签名字符串进行生成,如下所示。 true 注:如何进行签名生成sign值可参考【证书签名验签】说明帖子。 6、编写完相关的页面代码后,进行拼接地址链接:外网地址+项目名称+编写好的页面(带有接收数据代码,验签代码和返回验签成功消息给支付宝代码)。 7、把拼接好的地址链接放在第3步骤截图页面上的应用网关上,点击确认按钮,如代码和配置的数据无误的情况下,就会显示激活成功。

保持可爱mmm 2020-05-07 10:56:40 0 浏览量 回答数 0

问题

后端服务器ECS常见问题

行者武松 2019-12-01 21:43:14 3357 浏览量 回答数 0

回答

XSS 攻击有两⼤要素: 攻击者提交恶意代码。浏览器执⾏恶意代码。 针对第⼀个要素:我们是否能够在⽤户输⼊的过程,过滤掉⽤户输⼊的恶意代码呢? 输⼊过滤 在⽤户提交时,由前端过滤输⼊,然后提交到后端。这样做是否可⾏呢? 答案是不可⾏。⼀旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。 那么,换⼀个过滤时机:后端在写⼊数据库前,对输⼊进⾏过滤,然后把“安全的”内容,返回给前端。这样是否可⾏呢? 我们举⼀个例⼦,⼀个正常的⽤户输⼊了 5 < 7 这个内容,在写⼊数据库前,被转义,变成了 5 < 7 。 问题是:在提交阶段,我们并不确定内容要输出到哪⾥。 这⾥的“并不确定内容要输出到哪⾥”有两层含义: ⽤户的输⼊内容可能同时提供给前端和客户端,⽽⼀旦经过了 escapeHTML() ,客户端显示的内容就变成了乱码(5< 7)。 在前端中,不同的位置所需的编码也不同。 当5 < 7 作为 HTML 拼接⻚⾯时,可以正常显示: <div title="comment">5 < 7</div> 当5 < 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接⽤于 Vue 等模板的展示,也不能直接⽤于内容⻓度计算。不能⽤于标题、alert 等 所以,输⼊侧过滤能够在某些情况下解决特定的 XSS 问题,但会引⼊很⼤的不确定性和乱码问题。在防范 XSS 攻击时应避免此类⽅法 当然,对于明确的输⼊类型,例如数字、URL、电话号码、邮件地址等等内容,进⾏输⼊过滤还是必要的 既然输⼊过滤并⾮完全可靠,我们就要通过“防⽌浏览器执⾏恶意代码”来防范 XSS。这部分分为两类: 防⽌ HTML 中出现注⼊防⽌ JavaScript 执⾏时,执⾏恶意代码 预防存储型和反射型 XSS 攻击 存储型和反射型 XSS 都是在服务端取出恶意代码后,插⼊到响应 HTML ⾥的,攻击者刻意编写的“数据”被内到“代码”中,被浏览器所执⾏。 预防这两种漏洞,有两种常⻅做法: 改成纯前端渲染,把代码和数据分隔开。对 HTML 做充分转义。 纯前端渲染 纯前端渲染的过程: 浏览器先加载⼀个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。然后浏览器执⾏ HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据,调⽤ DOM API 更新到⻚⾯上。 在纯前端渲染中,我们会明确的告诉浏览器:下⾯要设置的内容是⽂本( .innerText ),还是属性( .setAttribute ),还是样式( .style )等等。浏览器不会被轻易的被欺骗,执⾏预期外的代码了。 但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx 等,请参考下⽂”预防 DOM 型 XSS 攻击“部分)。 在很多内部、管理系统中,采⽤纯前端渲染是⾮常合适的。但对于性能要求⾼,或有 SEO 需求的⻚⾯,我们仍然要⾯ 对拼接 HTML 的问题。 转义 HTML 如果拼接 HTML 是必要的,就需要采⽤合适的转义库,对 HTML 模板各处插⼊点进⾏充分的转义。 常⽤的模板引擎,如 doT.js、ejs、FreeMarker 等,对于 HTML 转义通常只有⼀个规则,就是把 & < > " ' / 这⼏个字符转义掉,确实能起到⼀定的 XSS 防护作⽤,但并不完善: 所以要完善 XSS 防护措施,我们要使⽤更完善更细致的转义策略。 例如 Java ⼯程⾥,常⽤的转义库为 org.owasp.encoder 。以下代码引⽤⾃ org.owasp.encoder 的官⽅说明。 <!-- HTML 标签内⽂字内容 --> <div><%= Encode.forHtml(UNTRUSTED) %></div> <!-- HTML 标签属性值 --> <input value="<%= Encode.forHtml(UNTRUSTED) %>" /> <!-- CSS 属性值 --> <div style="width:<= Encode.forCssString(UNTRUSTED) %>"> <!-- CSS URL --> <div style="background:<= Encode.forCssUrl(UNTRUSTED) %>"> <!-- JavaScript 内联代码块 --> <script> var msg = "<%= Encode.forJavaScript(UNTRUSTED) %>"; alert(msg); </script> <!-- JavaScript 内联代码块内嵌 JSON --> <script> var __INITIAL_STATE__ = JSON.parse('<%= Encoder.forJavaScript(data.to_json) %>'); </script> <!-- HTML 标签内联监听器 --> <button onclick="alert('<%= Encode.forJavaScript(UNTRUSTED) %>');"> click me </button> <!-- URL 参数 --> <a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top"> <!-- URL 路径 --> <a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>"> <!-- URL. 注意:要根据项⽬情况进⾏过滤,禁⽌掉 "javascript:" 链接、⾮法 scheme 等 --> <a href='<%= urlValidator.isValid(UNTRUSTED) ? Encode.forHtml(UNTRUSTED) : "/404" %>'> link </a> 可⻅,HTML 的编码是⼗分复杂的,在不同的上下⽂⾥要使⽤相应的转义规则。 预防 DOM 型 XSS 攻击 DOM 型 XSS 攻击,实际上就是⽹站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执⾏了。 在使⽤ .innerHTML 、 .outerHTML 、 document.write() 时要特别⼩⼼,不要把不可信的数据作为 HTML 插到⻚⾯上,⽽应尽量使⽤ .textContent 、 .setAttribute() 等。 如果⽤ Vue/React 技术栈,并且不使⽤ v-html / dangerouslySetInnerHTML 功能,就在前端 render 阶段避免innerHTML 、 outerHTML 的 XSS 隐患。 DOM 中的内联事件监听器,如 location 、 onclick 、 onerror 、 onload 、 onmouseover 等, 标签的 href 属性,JavaScript 的 eval() 、 setTimeout() 、 setInterval() 等,都能把字符串作为代码运⾏。如果不可信的数据拼接到字符串中传递给这些 API,很容易产⽣安全隐患,请务必避免。 <!-- 内联事件监听器中包含恶意代码 --> ![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/3e724ce0.data:image/png,) <!-- 链接内包含恶意代码 --> <a href="UNTRUSTED">1</a> <script> // setTimeout()/setInterval() 中调⽤恶意代码 setTimeout("UNTRUSTED") setInterval("UNTRUSTED") // location 调⽤恶意代码 location.href = 'UNTRUSTED' // eval() 中调⽤恶意代码 eval("UNTRUSTED") </script> 如果项⽬中有⽤到这些的话,⼀定要避免在字符串中拼接不可信数据。 其他 XSS 防范措施 虽然在渲染⻚⾯和执⾏ JavaScript 时,通过谨慎的转义可以防⽌ XSS 的发⽣,但完全依靠开发的谨慎仍然是不够的。 以下介绍⼀些通⽤的⽅案,可以降低 XSS 带来的⻛险和后果。 Content Security Policy 严格的 CSP 在 XSS 的防范中可以起到以下的作⽤: 禁⽌加载外域代码,防⽌复杂的攻击逻辑禁⽌外域提交,⽹站被攻击后,⽤户的数据不会泄露到外域禁⽌内联脚本执⾏(规则较严格,⽬前发现 GitHub 使⽤)禁⽌未授权的脚本执⾏(新特性,Google Map 移动版在使⽤)合理使⽤上报可以及时发现 XSS,利于尽快修复问题 输⼊内容⻓度控制 对于不受信任的输⼊,都应该限定⼀个合理的⻓度。虽然⽆法完全防⽌ XSS 发⽣,但可以增加 XSS 攻击的难度。 其他安全措施 HTTP-only Cookie: 禁⽌ JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注⼊后也⽆法窃取此 Cookie。验证码:防⽌脚本冒充⽤户提交危险操作。 过滤 Html 标签能否防⽌ XSS? 请列举不能的情况? ⽤户除了上传 <script>alert('xss');</script> 还可以使⽤图⽚ url 等⽅式来上传脚本进⾏攻击 <table background="javascript:alert(/xss/)"></table> <img src="javascript:alert('xss')"> 还可以使⽤各种⽅式来回避检查, 例如空格, 回⻋, Tab <img src="javas cript: alert('xss')"> 还可以通过各种编码转换 (URL 编码, Unicode 编码, HTML 编码, ESCAPE 等) 来绕过检查 <img%20src=%22javascript:alert('xss');%22> <img src="javascript&#58alert(/xss/)">

前端问答 2019-12-23 12:43:05 0 浏览量 回答数 0

问题

隐私号码通话记录

猫饭先生 2019-12-01 21:00:47 1621 浏览量 回答数 0

问题

如何实现OSS错误响应?

青衫无名 2019-12-01 22:00:27 2973 浏览量 回答数 0

问题

API调用方式

云栖大讲堂 2019-12-01 21:07:55 1412 浏览量 回答数 0

回答

调用API可能出现的错误有四类:连接淘宝服务器错误、平台级错误、业务级错误和容器类错误。这四种类型的错误分别代表了开发者访问淘宝服务器、淘宝接入平台、后端业务和容器这几个层次上出现的问题。 2,连接淘宝服务器错误主要是http连接错误或者连接被重置被拒绝等,这类错误是开发者访问淘宝服务器出现的问题,请直接联系服务器管理员或通过网络搜索答案。 平台级错误 1,平台级错误是指错误码小于100的调用错误,这种错误一般是由于用户的请求不符合各种基本校验而引起的。 2,用户遇到这些错误的返回首先检查应用的权限、频率等情况,然后参照文档检验一下传入的参数是否完整且合法。 错误码 错误描述-英文 错误描述-中文 解决方案 3 Upload Fail 图片上传失败 将传入的图片格式改为正确的格式、适当的大小的图片放进消息体里面传输过来,如果传输仍然失败需要减小图片大小或者增加网络带宽进行尝试 7 App Call Limited 应用调用次数超限,包含调用频率超限 调整程序合理调用API,等限频时间过了再调用,淘客的调用频率是系统按照上个月交易额自动修改的,修改后的频率会在官方论坛首页以公告形式通知,开发者可自行查看 9 Http Action Not Allowed HTTP方法被禁止 请用大写的POST或GET,如果有图片等信息传入则一定要用POST才可以 10 Service Currently Unavailable 服务不可用 多数是由未知异常引起的,仔细检查传入的参数是否符合文档描述 11 Insufficient ISV Permissions 开发者权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 12 Insufficient User Permissions 用户权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 13 Insufficient Partner Permissions 合作伙伴权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 15 Remote Service Error 远程服务出错 API调用后端服务出错,首先查看自己的参数是否合法,如果参数没有问题请过一段时间再尝试 21 Missing Method 缺少方法名参数 传入的参数加入method字段 22 Invalid Method 不存在的方法名 传入的method字段必需是你所调用的API的名称,并且该API是确实存在的 23 Invalid Format 无效数据格式 传入的format必需为json或xml中的一种 24 Missing Signature 缺少签名参数 传入的参数中必需包含sign字段 25 Invalid Signature 无效签名 签名必需根据正确的算法算出来的。算法请见: http://open.taobao.com/dev/index.php/API签名算法 26 Missing Session 缺少SessionKey参数 传入的参数中必需包含session字段 27 Invalid Session 无效的SessionKey参数 传入的session必需是用户绑定session拿到的,如果报session不合法可能是用户没有绑定session或session过期造成的,用户需要重新绑定一下然后传入新的sessionKey 28 Missing App Key 缺少AppKey参数 传入的参数必需包含app_key字段 29 Invalid App Key 无效的AppKey参数 应用所处的环境跟选择的环境不一致,例如:应用处于沙箱测试环境,却选择在正式环境进行测试,可在合作伙伴后台或商家接入平台对该应用进行修改 30 Missing Timestamp 缺少时间戳参数 传入的参数中必需包含timestamp参数 31 Invalid Timestamp 非法的时间戳参数 时间戳,格式为yyyy-mm-dd hh:mm:ss,例如:2008-01-25 20:23:30。淘宝API服务端允许客户端请求时间误差为10分钟 32 Missing Version 缺少版本参数 传入的参数中必需包含v字段 33 Invalid Version 非法的版本参数 用户传入的版本号格式错误,必需为数字格式 34 Unsupported Version 不支持的版本号 用户传入的版本号没有被提供 40 Missing Required Arguments 缺少必选参数 API文档中设置为必选的参数是必传的,请仔细核对文档 41 Invalid Arguments 非法的参数 参数类型不对,例如:需要传入的是数字类型的,却传入了字符类型的参数 42 Forbidden Request 请求被禁止 目前没有控制 43 Parameter Error 参数错误 一般是用户传入参数非法引起的,请仔细检查入参格式、范围是否一一对应 47 Invalid encoding 编码错误 一般是用户做http请求的时候没有用UTF-8编码请求造成的 业务级错误 1,业务级错误是指用户通过平台初步的参数校验,进入后端业务流程所出现的,错误码大于100的错误。 2,以isv开头的一般都是isv的错误,这一类错误一般是由于用户提供的参数不合法或者不匹配造成的,因此isv应该根据错误信息检验是否传入了相应的信息,对于这一类错误建议改正后再重试。 3,以isp开头的错误一般是isp服务不可用或top平台连接后端服务时的错误,这些错误可能与后台服务端的服务可用性有关,建议用户在一段时间后重试。 4,错误响应是用户和服务器交互失败的最直接展示,isv在调用top服务时,如果调用失败,请尽量保留下错误日志以便进行后面的错误追查。 业务级父错误 产品线 错误码 用户 500 类目 510 交易 520 退款 521 商品 530 商品扩展 531 邮费模板 532 产品 540 物流 550 店铺 560 评价 570 淘宝客 580 系统 590 备案 591 增量 600 画报 620 江湖 630 分销 640 淘秀 650 收费 660 业务级子错误 子错误码格式 错误信息 归属方 是否可在程序中重试 isv.###-not-exist:*** 根据***查询不到### ISV 否 isv.missing-parameter:*** 缺少必要的参数*** ISV 否 isv.invalid-paramete:*** 参数***无效,格式不对、非法值、越界等 ISV 否 isv.invalid-permission 权限不够、非法访问 ISV 否 isv.parameters-mismatch:***-and-### 传入的参数***和###不匹配,两者有一定的对应关系 ISV 否 isv.***-service-error:### 调用***服务返回false,业务逻辑错误,###表示具体的错误信息 ISV 否 isp.***-service-unavailable 调用后端服务***抛异常,服务不可用 ISP 是 isp.remote-service-error 连接远程服务错误 ISP 是 isp.remote-service-timeout 连接远程服务超时 ISP 是 isp.remote-connection-error 远程连接错误 ISP 是 isp.null-pointer-exception 空指针异常错误 ISP 否 isp.top-parse-error api解析错误(出现了未被明确控制的异常信息) ISP 否 isp.top-remote-connection-timeout top平台连接后端服务超时 ISP 是 isp.top-remote-connection-error top平台连接后端服务错误,找不到服务 ISP 是 isp.top-mapping-parse-error top-mapping转换出错,主要是由于传入参数格式不对 ISP 否 isp.unknown-error top平台连接后端服务抛未知异常信息 ISP 是 容器类错误 容器类错误是指用户通过容器登录之后页面上出现的错误 错误码 错误描述(中文) 100 授权码已经过期 101 授权码在缓存里不存在,一般是用同样的authcode两次获取sessionkey 102 系统错误,建议清理浏览器缓存,稍后重试 103 appkey或者tid(插件ID)参数必须至少传入一个 104 appkey或者tid对应的插件不存在 105 插件的状态不对,不是上线状态或者正式环境下测试状态 106 没权限调用此app,由于插件不是所有用户都默认安装,所以需要用户和插件进行一个订购关系,这个错误一般是由于用户访问了自己没有订购的在线订购应用所造成的 107 系统错误,建议清理浏览器缓存,稍后重试 108 应用是自用型应用,只有自用型绑定用户才可以访问。 109,111 服务端在生成参数的时候出了问题,建议清理浏览器缓存,稍后重试 110 服务端在写出参数的时候出了问题 ,建议清理浏览器缓存,稍后重试 112 回调地址不正确,请检查回调地址,是否为空,或者含有top认为非法的字符。 113 用户没有同意授权

问问小秘 2019-12-02 02:12:57 0 浏览量 回答数 0

回答

在Logstore列表页面单击诊断可以查看当前Logstore的所有日志采集报错,本文档介绍具体报错类型及对应的处理方式。 若您遇到其他问题,请提交工单处理。 错误类型 错误说明 处理方式 LOGFILE_PERMINSSION_ALARM Logtail无权限读取指定文件。 检查服务器Logtail的启动账户,建议以root方式启动。 SPLIT_LOG_FAIL_ALARM 行首正则与日志行首匹配失败,无法对日志做分行。 检查行首正则正确性,如果是单行日志可以配置为.*。 MULTI_CONFIG_MATCH_ALARM 同一个文件,只能被一个Logtail的配置收集,不支持同时被多个Logtail配置收集。 说明 Docker标准输出可以被多个Logtail配置采集。 检查一个文件是否在多个配置中被收集,并删除多余的配置。 REGEX_MATCH_ALARM 正则表达式解析模式下,日志内容和正则表达式不匹配。 复制错误内容中的日志样例重新尝试匹配,并生成新的解析正则式。 PARSE_LOG_FAIL_ALARM JSON、分隔符等解析模式下,由于日志格式不符合定义而解析失败。 请单击错误信息,查看匹配失败的详细报错。 CATEGORY_CONFIG_ALARM Logtail采集配置不合法。 常见的错误为正则表达式提取文件路径作为Topic失败,其它错误请提工单解决。 LOGTAIL_CRASH_ALARM Logtail因超过服务器资源使用上限而崩溃。 请参考配置启动参数修改CPU、内存使用上限,如有疑问请提工单。 REGISTER_INOTIFY_FAIL_ALARM Linux下注册日志监听失败,可能由于没有文件夹权限或文件夹被删除。 检查Logtail是否有权限访问该文件夹或该文件夹是否被删除。 DISCARD_DATA_ALARM 配置Logtail使用的CPU资源不够或网络发送流控。 请参考配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单解决。 SEND_DATA_FAIL_ALARM 主账号未创建任何AccessKey。 Logtail客户端机器与日志服务的服务器端无法连通或者网络链路质量较差。 服务器端写入配额不足。 主账号创建AK。 检查本地配置文件/usr/local/ilogtail/ilogtail_config.json,执行curl <服务器地址>,查看是否有内容返回。 为Logstore增加Shard数目,以支持更大数据量的写入。 REGISTER_INOTIFY_FAIL_ALARM Logtail为日志目录注册的inotify watcher失败。 请检查目录是否存在以及目录权限设置。 SEND_QUOTA_EXCEED_ALARM 日志写入流量超出限制。 在控制台扩容分区。 READ_LOG_DELAY_ALARM 日志采集进度落后于日志产生进度,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。 请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 DROP_LOG_ALARM 日志采集进度落后于日志产生进度,且未处理的日志轮转超过20个,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。 请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 LOGDIR_PERMINSSION_ALARM 没有日志监控目录读取权限。 请检查日志监控目录是否存在,若存在请检查目录权限设置。 ENCODING_CONVERT_ALARM 编码转换失败。 请检查日志编码格式配置是否与日志编码格式一致。 OUTDATED_LOG_ALARM 过期的日志,日志时间落后超过12小时。可能原因: 日志解析进度落后超过12小时。 用户自定义时间字段配置错误。 日志记录程序时间输出异常。 查看是否存在READ_LOG_DELAY_ALARM。如存在按照READ_LOG_DELAY_ALARM处理方式解决,若不存在请检查时间字段配置。 检查时间字段配置。若时间字段配置正确,请检查日志记录程序时间输出是否正常。 如有疑问请提工单。 STAT_LIMIT_ALARM 日志采集配置目录中的文件数超限。 检查采集配置目录是否有较多的文件和子目录,合理设置监控的根目录和目录最大监控深度。 DROP_DATA_ALARM 进程退出时日志落盘到本地超时,此时会丢弃未落盘完毕的日志。 该报错通常为采集严重阻塞导致,请参考Logtail配置启动参数修改CPU使用上限或网络发送并发限制,如有疑问请提工单。 INPUT_COLLECT_ALARM 输入源采集异常。 请参考错误提示处理。 HTTP_LOAD_ADDRESS_ALARM http输入的address不合法。 请检查address合法性。 HTTP_COLLECT_ALARM http采集异常。 请根据错误提示排查,一般由于超时导致。 FILTER_INIT_ALARM 过滤器初始化异常。 一般由于过滤器的正则表达式非法导致,请根据提示修复。 INPUT_CANAL_ALARM MySQL binlog运行异常。 请根据错误提示排查。在配置更新时canal服务可能重启,服务重启的错误可以忽略。 CANAL_INVALID_ALARM MySQL binlog内部状态异常。 此错误一般由于运行时表的schema信息变更导致meta不一致,请确认报错期间是否在修改表的schema。其他情况请提工单。 MYSQL_INIT_ALARM MySQL初始化异常。 请参考错误提示处理。 MYSQL_CHECKPOING_ALARM MySQL checkpoint格式异常。 请确认是否修改该配置中的checkpoint相关配置,其他情况请提工单。 MYSQL_TIMEOUT_ALARM MySQL查询超时。 请确认MySQL服务器和网络是否异常。 MYSQL_PARSE_ALARM MySQL查询结果解析失败。 请确认MySQL配置的checkpoint格式是否匹配对应字段的格式。 AGGREGATOR_ADD_ALARM 向队列中添加数据失败。 这种情况是由于数据发送过快,若真实数据量很大,则无需关心。 ANCHOR_FIND_ALARM anchor插件错误、配置错误或存在不符合配置的日志。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的信息,检查相应的配置是否存在问题。 anchor cannot find key:配置中指定了SourceKey但日志中不存在对应的字段。 anchor no start:无法从SourceKey的值中找到Start对应的内容。 anchor no stop:无法从 SourceKey 的值中找到Stop对应的内容。 ANCHOR_JSON_ALARM anchor插件错误,对已配置的Start和Stop所确定的内容执行JSON展开时发生错误。 请单击错误查看详细报错,检查所处理的内容以及相关的配置,确定是否有配置错误或不合法日志。 CANAL_RUNTIME_ALARM binlog插件运行时错误。 请单击错误查看详细报错,根据错误信息进行进一步地排查,错误一般与所连接的MySQL master相关。 CHECKPOINT_INVALID_ALARM 插件内Checkpoint解析失败。 请单击错误查看详细报错,根据其中的检查点键、检查点内容(前 1024 个字节)以及具体的错误信息进行进一步排查。 DIR_EXCEED_LIMIT_ALARM Logtail同时监听的目录数超出限制。 检查当前Logstore的采集配置以及该Logtail上应用的其他配置是否会包含较多的目录数,合理设置监控的根目录和目录最大监控深度。 DOCKER_FILE_MAPPING_ALARM 执行Logtail命令添加Docker文件映射失败。 请单击错误查看详细报错,根据其中的命令以及具体的错误信息进行进一步排查。 DOCKER_FILE_MATCH_ALARM 无法在Docker容器中查找到指定文件。 请单击错误查看详细报错,根据其中的容器信息以及查找的文件路径进行进一步排查。 DOCKER_REGEX_COMPILE_ALARM docker stdout插件错误,根据配置中的BeginLineRegex构建正则表达式失败。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 DOCKER_STDOUT_INIT_ALARM docker stdout采集初始化失败。 请单击错误查看详细报错,报错根据内容分为以下几类: host...version...error:请检查配置中指定的Docker engine是否可访问。 load checkpoint error:加载检查点失败,如无影响可忽略此错误。 container...:指定容器存在非法label值,目前仅允许配置stdout和stderr。请结合详细错误进行检查。 DOCKER_STDOUT_START_ALARM Docker stdout初始化采集时,stdout文件大小超过限制。 一般由于首次采集时stdout文件已存在,可忽略。 DOCKER_STDOUT_STAT_ALARM Docker stdout无法检查到stdout文件。 一般由于容器退出时无法访问到文件,可忽略。 FILE_READER_EXCEED_ALARM Logtail同时打开的文件对象数量超过限制。 一般由于当前处于采集状态的文件数过多,请检查采集配置是否合理。 GEOIP_ALARM geoip插件错误。 请单击错误查看详细报错,报错根据内容分为以下几类: invalid ip...:获取IP地址失败,请检查配置中的 SourceKey 是否正确或是否存在不合法日志。 parse ip...:根据IP地址解析城市失败,请查看详细错误信息进行排查。 cannot find key...:无法从日志中查看到指定的SourceKey,请检查配置是否正确或是否存在不合法日志。 HTTP_INIT_ALARM http插件错误,配置中指定的ResponseStringMatch正则表达式编译错误。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 HTTP_PARSE_ALARM http插件错误,获取HTTP响应失败。 请单击错误查看详细报错,根据其中的具体错误信息对配置内容或所请求的HTTP服务器进行检查。 INIT_CHECKPOINT_ALARM binlog插件错误,加载检查点失败,插件将忽略检查点并从头开始处理。 请单击错误查看详细报错,根据其中的具体错误信息来确定是否可忽略此错误。 LOAD_LOCAL_EVENT_ALARM Logtail执行了本地事件处理。 此警告一般不会出现,如果非人为操作引起此警告,才需要进行错误排查。请单击错误查看详细报错,根据其中的文件名、配置名、project、logstore等信息进行进一步地排查。 LOG_REGEX_FIND_ALARM processor_split_log_regex以及 processor_split_log_string插件错误,无法从日志中获取到配置中指定的 SplitKey。 请单击错误查看详细报错,检查是否存在配置错误的情况。 LUMBER_CONNECTION_ALARM service_lumberjack插件错误,停止插件时关闭服务器错误。 请单击错误查看详细报错,根据其中的具体错误信息进行进一步排查,此错误一般可忽略。 LUMBER_LISTEN_ALARM service_lumberjack插件错误,初始化进行监听时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类: init tls error...:请结合具体的错误信息检查 TLS 相关的配置是否正确 listen init error...:请结合具体的错误信息检查地址相关的配置是否正确。 LZ4_COMPRESS_FAIL_ALARM Logtail执行LZ4压缩发生错误。 请单击错误查看详细报错,根据其中的log lines、project、category、region等值来进行进一步排查。 MYSQL_CHECKPOINT_ALARM MySQL插件错误,检查点相关错误。 请单击错误查看详细报错,报错根据内容分为以下几类: init checkpoint error...:初始化检查点失败,请根据错误信息检查配置指定的检查点列以及所获取的值是否正确。 not matched checkpoint...:检查点信息不匹配,请根据错误信息检查是否是由于配置更新等人为原因导致的错误,如果是则可忽略。 NGINX_STATUS_COLLECT_ALARM nginx_status插件错误,获取状态发生错误。 请单击错误查看详细报错,根据其中的URL以及具体的错误信息来进行进一步排查。 NGINX_STATUS_INIT_ALARM nginx_status插件错误,初始化解析配置中指定的URL失败。 请单击错误查看详细报错,根据其中的URL检查地址是否正确配置。 OPEN_FILE_LIMIT_ALARM Logtail已打开文件数量超过限制,无法打开新的文件。 请单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。 OPEN_LOGFILE_FAIL_ALARM Logtail打开文件出错。 请单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。 PARSE_DOCKER_LINE_ALARM service_docker_stdout插件错误,解析日志失败。 请单击错误查看详细报错,报错根据内容分为以下几类: parse docker line error: empty line:日志为空。 parse json docker line error...:以JSON格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。 parse cri docker line error...:以CRI格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。 PLUGIN_ALARM 插件初始化及相关调用发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据具体的错误信息进行进一步排查。 init plugin error...:初始化插件失败。 hold on error...:暂停插件运行失败。 resume error...:恢复插件运行失败。 start service error...:启动 service input类型的插件失败。 stop service error...:停止 service input类型的插件失败。 PROCESSOR_INIT_ALARM regex插件错误,编译配置中指定的Regex正则表达式失败。 请单击错误查看详细报错,检查其中的正则表达式是否正确。 PROCESS_TOO_SLOW_ALARM Logtail日志解析速度过慢。 单击错误查看详细报错,根据其中的日志数量、缓冲区大小、解析时间来确定是否正常。 如果不正常,检查Logtail所在节点是否有其他进程占用了过多的CPU资源或是存在效率较低的正则表达式等不合理的解析配置。 REDIS_PARSE_ADDRESS_ALARM redis插件错误,配置中提供的ServerUrls存在解析失败的情况。 请单击错误查看详细报错,对其中报错的URL进行检查。 REGEX_FIND_ALARM regex 插件错误,无法从日志中找到配置中SourceKey指定的字段。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 REGEX_UNMATCHED_ALARM regex插件错误,匹配失败。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据具体的错误信息进行进一步地排查,例如检查配置是否正确。 unmatch this log content...:日志无法匹配配置中的正则表达式 match result count less...:匹配的结果数量少于配置中指定的 Keys 数量。 SAME_CONFIG_ALARM 同一个Logstore下存在同名的配置,后发现的配置会被抛弃。 请单击错误查看详细报错,根据其中的配置路径等信息排查是否存在配置错误的情况。 SPLIT_FIND_ALARM split_char以及split_string插件错误,无法从日志中找到配置中SourceKey指定的字段。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 SPLIT_LOG_ALARM processor_split_char以及processor_split_string插件错误,解析得到的字段数量与SplitKeys中指定的不相同。 请单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 STAT_FILE_ALARM 插件内通过LogFileReader对象进行文件采集时发生错误。 请单击错误查看详细报错,根据其中的文件路径、错误信息进行进一步排查。 SERVICE_SYSLOG_INIT_ALARM service_syslog插件错误,初始化失败。 请单击错误查看详细报错,检查配置中的Address是否正确。 SERVICE_SYSLOG_STREAM_ALARM service_syslog插件错误,通过TCP采集时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的具体错误信息进行排查。 accept error...:执行Accept时发生错误,插件将等待一段时间后重试。 setKeepAlive error...:设置 Keep Alive失败,插件将跳过此错误并继续运行。 connection i/o timeout...:通过TCP读取时超时,插件将重设超时并继续读取。 scan error...:TCP 读取错误,插件将等待一段时间后重试。 SERVICE_SYSLOG_PACKET_ALARM service_syslog插件错误,通过UDP采集时发生错误。 请单击错误查看详细报错,报错根据内容分为以下几类,请根据详细报错中的具体错误信息进行排查。 connection i/o timeout...:通过UDP读取时超时,插件将重设超时并继续读取。 read from error...:UDP读取错误,插件将等待一段时间后重试。

保持可爱mmm 2020-03-26 23:02:18 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站