iOS post 的坑

最新推荐文章于 2023-05-05 06:38:04 发布
原创 最新推荐文章于 2023-05-05 06:38:04 发布 · 883 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

今天由于项目原因，利用原生，自己封装了HTTP请求的post，却服务器一直返回表示body是空的。

经过排查和Google后，终于发现了问题

下面主要提下注意事项和解决方法：

1、body需要处理过

[request setHTTPBody: [body dataUsingEncoding:NSUTF8StringEncoding]];

2、body有好几组设置方式。具体是哪些原谅我基础知识差，如果有清楚的请告知

经过资料查找后，发现需要在header里添加两个值

[requestsetValue:[NSStringstringWithFormat:@"%lu",postData.length]forHTTPHeaderField:@"Content-Length"];

[requestsetValue:@"application/x-www-form-urlencoded charset=utf-8"forHTTPHeaderField:@"Content-Type"];


其中postData是已经处理过的


3、关于Xcode的optimization

具体原因不是很清楚，但是一般情况下，release下的选择是最优。

但是最优却导致我body传值是空的

断点下，po可以得到值，但是实例化却拿不到，建议关掉：



提示：如果Xcode有下图警告，关掉！




iOS文件上传遇到的坑
wentianen的博客
06-19 9895
背景在我们的app中有一些需要做文件上传的功能，最近在我们对文件上传结果的日志监控中收到了很多的超时信息，后来在实际文件上传的测试中发现一些问题，主要集中在大批文件上传上面，简单分享一下。问题在批量文件上传中，通过测试发现，使用NSURLSessionUploadTask的形式进行文件上传，如果同时启动过多的上传任务，会导致上传任务的失败率极高，失败的原因基本都是请求超时。按照以下方式对文件上传进行
iOS中使用AFN的delete请求遇到的坑
qq_22945837的博客
02-13 3421
事情是这样的：我们公司的项目中有地方用到删除功能，服务器端给提供了删除接口 使用的是delete请求方式，我度娘查看了delete的相关问题写的都很少，然后自己摸索二次封装了delete。然后传参，服务器端要传的是类似post请求的body体中的数据 也就是传一个字典过去 ，那么我就把字典给他传过去呗，结果是服务器死活收不到这个我传过去的字典数据，然后就是我跟后台联调，发现我传过去的是将字典拆分后
request 请求body丢失
huzhaohao的专栏
03-12 4022
刚接触搞IOS，这个问题也是困扰了好久，今天终于解决了。关键少了一段断码：[request setValue:@"application/octet-stream" forHTTPHeaderField:@"Content-Type"]; 这个必须设置。    //拼接URL字符串    NSString *strUrl = [NSString stringWithFormat:@"http://...
NSURLProtocol 拦截 NSURLSession 请求时body丢失问题解决方案探讨
weixin_34212762的博客
03-26 380
摘要： “IP直连方案”主要在于解决DNS污染、省去DNS解析时间，通常情况下我们可以在项目中使用 NSURLProtocol 拦截 NSURLSession 请求，下面将支持 Post 请求中面临的一个挑战，以及应对策略介绍一下。“IP直连方案”主要在于解决DNS污染、省去DNS解析时间，通常情况下我们可以在项目中使用 NSURLProtocol 拦截 NSURLSession 请求，下面将支持...
iOS上的http请求：get、post以及同步、异步
青春的岁月流逝
07-07 1160
1、get: view sourceprint? 01.<span style="font-size:14px;">NSString * URLString = @"http://webservice.webxml.com.cn/WebServices/WeatherWS.asmx/getSupportCityDataset?theRegionCod
AFNetworking 3.0封装post请求body里面内容是空的
opentogether的博客
06-01 5125
AFNetworking 3.0封装post请求body里面内容是空的
ios发送post请求(包括txt和image)的完整例子
06-18
代码里实现了发送post请求给服务器，包括发送text文件和image
小程序兼容安卓和IOS数据处理问题及坑
10-18
### 微信小程序在Android和iOS上的数据处理问题 在微信小程序的开发过程中，处理与后端服务器的数据交互是至关重要的一环。但由于Android和iOS这两个平台在系统架构、API设计上的差异，以及微信小程序自身的限制，...
精选资源
项目中axios发送 post 请求 数据类型为Form Data 数据时踩的坑（设置了请求头信息之后还未成功 但是发送过去的类型不对）解决方法
01-03
项目中post后端要求发送的数据放在formdata中， 那么第一件事情设置请求头信息，，现在用的很多封装的ajax库都可以设置请求头信息 这里以axios为例 axios({ url:this.dialog.add.upload_url, method:'post', data...
iOS_POST_网络请求
江月夜
07-21 2142
同步的 post 请求#pragma mark - 同步的 post 请求 - (IBAction)POSTSynButtonDidClicked:(UIButton *)sender { // 1、拼接 baseUrlString NSString *baseUrlString = @"http://ipad-bjwb.bjd.com.cn/DigitalPublication/pu
post请求body丢失问题
心若有所栖，何似风飘缈。
08-19 1万+
问题描述： 在做g*j*j*项目的时候出现了线上环境一个接口的详情页body丢失问题， 可是在开发环境和测试环境却能正常运行，该接口使用的post请求； 通过日志知道后端服务器发送给前端服务器的body是有数据的。经查阅和推理得出以下论断：1.get请求不带body，而post请求带body和content_length； 按理说后端是已经接收到了前端的数据，所以这一段不会出...
ios开发系列之Get与Post方式请求数据
鬼谷传人的博客
10-23 2405
在说请求数据之前,我们先了解下URL URL(Uniform Resource Locator) 统一资源定位符 格式为:protocol(协议) hostname(主机名) port(端口号) path(路径)parameters(参数)其中hostname 也可以换成主机ip地址, 相当于域名,给ip地址带个面具(mask),方便大家记忆 通过URL 我们可以找到服务器上的资源位置,然后客
iOS 关于post异步请求
cxiao_11的博客
04-29 1128
-(void)loadData {     [self showhudView];     hud = [[JGProgressHUD alloc]initWithStyle:JGProgressHUDStyleDark];     hud.textLabel.text = @"正在加载......";     [hud showInView:_hudView animated:YES]
postman可正常请求第三方接口，但postMethod请求时，服务端接收body为空
OUCFSB的博客
12-29 2506
问题描述： 项目对接一个第三方接口，使用postMethod的方式发送请求。发现服务器端接收到的请求，body为空。但打印请求日志时，请求参数已正常加载。使用postman测试时，可正常访问。 请求代码如下： SignResponse res=new SignResponse(); HttpClient hc=new HttpClient(); PostMethod postmethod = new PostMethod(requestURL); postmethod.setRequestHea
Okhttp post 发送空的body
李某人_
11-15 1万+
如果你还不知道okhttp那真的是太OUT了，公司最近登录接口需要post请求，但是最重要的是不需要再body里面进行传值，所以有了今天这个文章！ 话不多说直接上代码： private Call requestPostByUrl(String actionUrl, HashMap paramsMap, final ReqCallBack callBack) { StringB
HttpServletRequest读取数据body为空的问题
热门推荐
刘阳的博客
04-18 1万+
最近新换了一个工作，节奏刚刚调整过来，这段时间没有写东西，有点惭愧，后续还是要回归正确的节奏，争取一周至少一篇。本篇记录下新工作中第一次上线踩到的一个坑，这个坑如果之前没有踩过，真的很难发现，在此记录一下，提醒下其他人避免重复犯错。问题背景本次需求有一项需要区分压测来源的数据，将压测的日志单独区分，不要打到线上正常日志中。这里比较简单，从request的header或者parameter中获取下压...
C#向硬件或单片机服务器发起POST请求，后台断点测得Body主体为空的解决方法
阿修罗汉果茶的博客
11-14 1261
用HttpWebReques,WebClient在抓包和Web下数据正常，但是去向某个硬件后台发起POST请求时，Body会为空。就算设置Expect100Continue和Connetion也无法解决问题。
req.body为空的原因可能有以下几点：
526大飞哥
05-05 1454
数据提交
HttpServletRequest读取数据body为空
Sunjin_shuai的博客
08-27 3956
近期对接了君子签，在对接过程中回调接口遇到了一个问题 君子签回调是post请求 请求的类型是请求的类型（Content-Type头）是application/x-www-form-urlencoded 发现从request.getInputStream()中获取的body为空， body在正常情况下都是不为空的，之后检查认为是request读取body之前，调用了getParamet...
uniapp ios finishTransaction 没有关闭订单
最新发布
11-06
<think>我们正在处理的问题是：在uni-app中使用苹果IAP支付时，使用finishTransaction方法未关闭订单的解决方案。 根据引用[1]和引用[2]的内容，我们可以总结出以下关键点： 1. 引用[1]中提到，建议将`manualFinishTransaction`设置为`true`，手动关闭订单，以避免自动关闭订单可能出现订单关闭失效的情况。 2. 引用[2]中提到，在支付参数中设置`optimize: true`可以解决丢单问题。 因此，解决方案应该是： - 在调用`uni.requestPayment`时，在`orderInfo`参数中设置`manualFinishTransaction: true`，表示手动关闭订单。 - 同时，根据引用[2]的经验，设置`optimize: true`可以帮助解决丢单问题。 手动关闭订单意味着在支付成功回调中，我们需要自己调用`finishTransaction`方法来关闭订单。但是，在uni-app的API文档中，并没有直接提供`finishTransaction`方法。实际上，uni-app的API中，苹果IAP支付的回调成功函数会返回一个`Transaction`对象（如引用[1]中注释所示），这个对象应该包含关闭交易的方法。 然而，查阅uni-app官方文档关于苹果IAP支付的部分，我们发现：在支付成功的回调中，我们可以得到交易对象（Transaction），然后使用该对象的`finish`方法来关闭交易。 步骤： 1. 在调用支付时，设置`manualFinishTransaction: true`，这样支付成功后不会自动关闭订单，而是等待我们手动关闭。 2. 在支付成功的回调中，获取到交易对象（即success回调函数的参数e），然后调用该交易对象的`finish`方法（注意：在uni-app中，这个方法可能叫做`finish`，也可能需要查看具体文档）。 但是，注意引用[1]中代码注释： // e 类型为 Transaction, 详见下面的描述 因此，我们需要在成功回调中处理交易对象，调用其`finish`方法。 根据uni-app官方文档（由于没有直接给出，我们根据经验推测），通常交易对象会有一个`finishTransaction`或者`finish`方法。但是，在uni-app的API中，苹果IAP支付成功回调返回的Transaction对象有一个`finish`方法。 参考：[uni-app IAP支付文档](https://uniapp.dcloud.io/api/plugins/payment?id=iap)（注意：实际文档可能更新，这里根据经验回答） 在文档中，Transaction对象包含以下字段： - transactionState: 交易状态 - payload: 支付数据 - transactionIdentifier: 交易标识 - transactionDate: 交易日期 - productid: 产品id - quantity: 数量 - applicationUsername: 透传参数 - finish: 方法，用于结束交易 因此，我们可以在成功回调中调用`e.finish()`来手动关闭交易。 但是，请注意：我们必须在确认我们的服务器已经成功处理了该笔订单（即已经将商品发放给用户）之后，再调用`finish`方法。因为一旦调用了`finish`，交易就结束了，如果此时我们的服务器还没有处理成功，那么用户可能支付了钱却没有得到商品，而交易已经无法恢复了。 所以，正确的步骤是： 1. 支付成功回调中，我们收到交易对象e。 2. 将交易信息（比如transactionIdentifier等）发送给我们的服务器，由服务器向苹果服务器验证订单并处理发货等。 3. 服务器处理成功并返回确认后，我们再调用`e.finish()`结束交易。 如果服务器处理失败（比如网络问题、服务器错误等），则不应该调用`finish`，这样交易会处于未完成状态，苹果会尝试重新通知（具体机制是，每次应用启动时，未完成的交易会再次被通知到应用）。 因此，代码逻辑大致如下： ```javascript uni.requestPayment({ provider: 'appleiap', orderInfo: { manualFinishTransaction: true, // 手动关闭订单 username: '用户的唯一标识', // 透传参数，可选 productid: '产品ID', // 必须 optimize: true // 优化参数，防止丢单，引用[2]中提到 }, success: async (e) => { // e 是交易对象 console.log('支付成功，交易对象:', e); // 将交易信息发送给服务器，等待服务器验证并处理 try { // 假设我们有一个函数发送交易信息到服务器，并等待服务器处理 const serverResult = await sendPaymentToServer({ transactionIdentifier: e.transactionIdentifier, productid: e.productid, // 其他需要的信息 }); if (serverResult.success) { // 服务器处理成功，结束交易 e.finish(); // 调用交易对象的finish方法 } else { // 服务器处理失败，不结束交易，等待下次通知 // 可以记录错误，并提示用户稍后再试 console.error('服务器处理订单失败:', serverResult.message); // 注意：这里不调用finish，那么交易会保留，以后会再次通知 // 但是，我们也可以考虑在适当的时候（比如应用退出前）再次尝试处理？ } } catch (error) { console.error('发送订单到服务器失败:', error); // 同样，不结束交易 } }, fail: (err) => { console.error('支付失败:', err); } }); ``` 注意：由于苹果要求必须在处理完订单后调用`finish`，否则会导致订单重复通知等问题，所以一定要确保在服务器处理成功后才调用。 另外，引用[1]中提到“踩过的坑：回调时间长，导致掉单”。因此，我们需要注意： - 在回调中，如果长时间不调用finish，可能会导致苹果的支付队列阻塞，进而影响其他支付。 - 因此，服务器验证订单的接口需要快速响应。如果服务器验证过程较长，我们可以先调用`e.finish()`再处理？但这样有风险，因为如果调用finish后服务器处理失败，则无法恢复交易。所以，更安全的做法是服务器处理成功后再调用finish。 但是，苹果官方建议：在将支付信息发送到服务器后，就可以调用finish（而不必等待服务器处理完成）？实际上，这样是不安全的，因为服务器可能处理失败。 所以，我们需要在安全性和及时释放交易之间权衡。通常，我们选择在服务器确认收到并验证订单后再调用finish。 为了避免长时间不调用finish，我们需要优化服务器验证订单的速度，并且设置超时处理。如果服务器验证请求超时，我们可以选择： - 不调用finish，然后等待下次交易通知（苹果会在应用启动时再次通知未完成的交易），然后再次尝试处理。 - 或者，我们可以将交易信息暂存（比如本地存储），然后稍后重试，并调用finish。 不过，苹果的机制是：只要交易没有finish，那么每次应用启动，都会再次收到该交易的支付成功回调。所以，我们可以借助这个机制来保证最终处理成功。 因此，我们可以这样设计： - 每次收到支付成功回调，我们都尝试将交易信息发送给服务器，直到服务器返回明确的成功（或失败，比如订单已处理过），然后调用finish。 为了避免重复处理同一个交易，我们需要在服务器端记录已经处理过的交易标识（transactionIdentifier）。 总结解决方案： 1. 在支付时设置`manualFinishTransaction: true`和`optimize: true`。 2. 在支付成功回调中，将交易信息（特别是transactionIdentifier）发送给服务器进行验证和处理。 3. 服务器处理成功后，再调用交易对象的`finish()`方法。 4. 如果服务器处理失败，则不要调用`finish`，等待下次应用启动时再次收到该交易的通知，然后再次尝试处理。 另外，根据引用[2]中的代码，他们使用了`optimize: true`来解决丢单问题，所以我们也加上这个参数。 注意：`optimize`参数是uni-app提供的一个优化参数，具体作用可能是优化了回调的时机，避免丢单。 最后，关于`finish`方法的具体调用方式，请以uni-app最新官方文档为准。 如果按照以上步骤仍然出现未关闭订单的情况，请检查： - 是否确实调用了`e.finish()`（确保执行到了这一行）。 - 服务器处理订单的时间是否过长，导致苹果支付超时（虽然我们不调用finish，苹果会重试，但长时间不finish可能会被苹果视为异常）。 - 交易对象e是否确实有`finish`方法（可以通过打印e对象来查看）。 如果还有问题，可以考虑查阅uni-app的官方文档或社区。 引用： [^1]: 引用自站内引用[1] [^2]: 引用自站内引用[2] </think>基于提供的引用信息和问题描述，以下是解决 Uniapp 在 iOS 系统中 `finishTransaction` 方法未关闭订单的完整方案： ### 解决方案步骤 1. **启用手动关闭订单模式** 在 `uni.requestPayment` 的 `orderInfo` 参数中设置 `manualFinishTransaction: true`： ```javascript uni.requestPayment({ provider: 'appleiap', orderInfo: { manualFinishTransaction: true, // ✅ 关键配置：手动关闭订单 username: '用户唯一标识', // 透传用户ID（可选但推荐） productid: '产品ID', // App Store Connect 配置的产品ID optimize: true // ✅ 优化参数，防止丢单 }, success: (e) => { // 此处添加手动关闭逻辑 ↓ } }) ``` *引用自踩坑经验：自动关闭订单可能导致关闭失效[^1]* 2. **在支付回调中手动关闭订单** 支付成功后，通过交易对象（`Transaction`）的 `finish()` 方法显式关闭订单： ```javascript success: (e) => { console.log('支付成功', e.transactionIdentifier); // 1. 发送交易凭证到服务端验证 uni.request({ url: 'https://your-server.com/verify-iap', method: 'POST', data: { transaction: e }, success: (res) => { if (res.data.valid) { // 2. 验证通过后手动关闭订单 e.finish(); // ✅ 关键调用 console.log('订单已关闭'); } } }); } ``` *注意：必须先完成服务端验证再调用 `finish()`，避免商品未发放[^2]* 3. **处理未完结的遗留订单** 在应用启动时检查未关闭的订单： ```javascript // App.vue 的 onLaunch 中 uni.getProvider({ service: 'payment', success: (res) => { if (res.providers.includes('appleiap')) { const iap = uni.requireNativePlugin('AppleIAP'); iap.restoreCompletedTransactions(transactions => { transactions.forEach(tx => { // 重新验证并关闭历史订单 tx.finish(); }); }); } } }); ``` ### 关键注意事项 1. **防丢单优化** 务必设置 `optimize: true` 参数，解决苹果IAP回调延迟导致的丢单问题（引用自经验[^2]） 2. **服务端验证要求** - 必须在服务端用 Apple 官方接口验证交易凭证 - 验证通过前切勿调用 `finish()`，否则可能无法恢复失败交易 - 典型验证流程： ```mermaid graph TD A[客户端获取Transaction] --> B[发送到服务端] B --> C{苹果验证接口} C -->|有效| D[发放商品] D --> E[返回成功给客户端] E --> F[客户端调用finish] ``` 3. **常见错误处理** | 错误码 | 原因 | 解决方案 | |--------|-----------------------|------------------------| | -100 | 订单信息返回失败 | 检查 `productid` 配置 | | -102 | 交易已关闭 | 忽略重复回调 | | 0 | 沙盒测试环境证书错误 | 使用正式环境证书 | > **提示**：完整文档参考 [Uniapp IAP 支付指南](https://uniapp.dcloud.net.cn/api/plugins/payment.html#iap) ### 相关问题 1. 如何验证苹果IAP支付凭证的真伪？ 2. iOS 沙盒测试 IAP 时需要哪些特殊配置？ 3. 除了 `manualFinishTransaction`，还有哪些防止 IAP 丢单的有效措施？ *** 参考文献： [^1]: 手动关闭订单配置建议及踩坑记录 [^2]: IAP 支付错误 code -100 的解决方案及优化参数说明
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值