V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  also24  ›  全部回复第 191 页 / 共 286 页
回复总数  5704
1 ... 187  188  189  190  191  192  193  194  195  196 ... 286  
@MrCurly #1
这不是老生常谈的事儿嘛:故意砍掉 “甜点” 容量,强迫你购买更大容量的产品。
有一个公益广告,小时候看过的,之前找了好久找不到,不知道楼主能不能帮忙找到。

场景 1:
公交车上,有人扔了个易拉罐在地上,女售票员过来捡了起来,骂道“有没有公德心啊”,然后把易拉罐从窗口扔了出去。

场景 2:
路边小吃摊,男主坐下以后,看着桌面上的一次性筷子发愁“这每年要吃掉多少森林啊”,这时菜上桌了,男主掰开筷子开始吃饭。

场景 3:
印象中还有一个关于野生动物的,记不清情节了。

每个场景结束时,会有一个字幕:
你已经意识到了“....”,只是还需要做的更多一点(大意如此)
2019-09-10 01:21:14 +08:00
回复了 kid1412621 创建的主题 Android Android 有像 iOS opener 这种自定义 schema 跳转的 App 吗?
@SingeeKing #1
> 但是最新的 releases 有较多 Bug,我重新从源码编译了程序,并打包了中文语言,可以做到开箱即用。
2019-09-08 17:19:05 +08:00
回复了 therethere9 创建的主题 问与答 感觉越来越多的 app 不支持 android 4.4 的手机了
Android KitKat ( 4.4 )是 Google 继 Android Jelly Bean 之后开发的 Android 移动操作系统,于 2013 年 10 月正式发布。

2013 年 9 月 10 日,苹果公司在 2013 秋季新品发布会上正式提供 iOS 7 下载更新。
2019-09-05 21:49:01 +08:00
回复了 zhenzinian 创建的主题 问与答 如果你是一名中学计算机课老师。。
@Marcustar #2
想推荐自家服务完全可以直接发啊,这又是何必呢?
https://meta.appinn.net/t/topic/7972
2019-09-05 11:21:43 +08:00
回复了 zhangH258 创建的主题 程序员 软硬件如何结合,后台是 PHP ,设备端没有思路
@jowan #7
这样来看应该就是手机 /平板吧
https://ws2.sinaimg.cn/large/760b39b3gy1g6oh5e509cj20xa06idgj.jpg
2019-09-05 09:46:37 +08:00
回复了 yitd 创建的主题 程序员 有没有什么方法判断浏览器是否支持 js
我隐隐的感觉这是个 X-Y 问题。

所以虽然前面已经有人问过,还是想再确认一下:
楼主你是确实业务中希望对不支持 JS 或禁用了 JS 的用户区别对待,还是想反爬虫?


单纯的区别对待,可以做的方案其实非常多,但是如果是为了反爬虫,那么很多方案并不能带来更多的复杂度。
2019-09-04 20:24:53 +08:00
回复了 YueZhang 创建的主题 职场话题 我请一个年假,我的领导就一副臭脸。太恶心了。
@Spaike
这里确实是我没讲清楚,我主要针对的是 “我的年假,我凭什么不能立即请假立即走” 这种想法,我的核心点还是在于 “互相沟通”。

这种想法在上一页,以及 /t/522131 这个帖子里都能看到很多,我觉得这种比较 “对立” 的想法是没必要的。
2019-09-04 15:02:35 +08:00
回复了 YueZhang 创建的主题 职场话题 我请一个年假,我的领导就一副臭脸。太恶心了。
@304464743 #105 @JohnSmith #106
没有毁灭性影响 ≠ 没有影响
请假未必会导致项目停摆甚至公司倒闭,但是影响是一定会有的。

如果可以通过三五句话的沟通,尽可能的减少这个影响,为什么不呢?
2019-09-04 14:19:29 +08:00
回复了 dxgfalcongbit 创建的主题 硬件 雷电 3 的电气成本决定了这玩意很难普及
@BingoXuan
@dxgfalcongbit

想要精确讨论这个问题,其实需要 “定量” 讨论,而不是 “定性” 讨论。

二位试图通过 “定性” 来得出一个结论,我觉得是很难有结果的。
2019-09-04 10:18:27 +08:00
回复了 dxgfalcongbit 创建的主题 硬件 雷电 3 的电气成本决定了这玩意很难普及
楼主提出的观点其实总共有 3 个:
1、雷电的电气成本(物料成本)高
2、因为 1,未来可能有通货膨胀导致雷电的实际价格高
3、因为 1,雷电很难普及


而 @BingoXuan 反驳的其实主要是第 2 第 3 点
2、雷电不止有固定成本(物料成本),也有边际成本(研发推广成本),后者是正在下降的
3、因为 2,对雷电的普及有更好的预期


其中,楼主更看重第 1 点结论,@BingoXuan 更看重第 3 点结论。
我觉得二位讲的似乎都没有错误,只需要搞清楚双方所针对的点就好了。
2019-09-04 01:18:26 +08:00
回复了 YueZhang 创建的主题 职场话题 我请一个年假,我的领导就一副臭脸。太恶心了。
类似的事,上次在微信群讨论的时候被其它人喷了,但是我还是想表达一下想法:

我不会主动去 “卡” 任何组员的请假,不管是调休还是事假。
但我不希望组员给我搞 “突然袭击”,只给我留极少的时间处理。
作为项目的负责人,我有责任保证即使成员请假,项目也能顺利进行。

我也有我的汇报对象,我也需要给他们一个交待:
组员请假的影响,是否在我的可控范围内?我是否做好了相应安排?项目计划是否会受到影响?

如果出现了 “工作未安排” 的请假,我确实会很焦虑,因为这是失控的情况。
我会做好准备,避免单个组员的突发情况导致项目停摆,但那是预防措施,如非必要我不希望启用。

我期望的状态是,除非事出紧急,组员在请假时,能够将心比心,主动提前告知我,
这并不是我 “不情愿” 你请假或者设置障碍,而是希望整个组整体的利益最大化。
事实上大部分情况下的 “安排”,也就短短三五句话沟通工作,真的占用不了多少时间。

注意,我强调了 “除非事出紧急”,如果确实是紧急情况,自然以急事为主,
这种情况下,只要说一声就够,甚至事后再说也行,请假手续也更是无所谓。



你有随时请假的权利,主管有不批假的权力,在诉求权利或使用权力时,其实都可以更柔和一些,
要求自己应得的权利是没有任何问题的,只是如果做事时多互相考虑一下,可能就减少了许多冲突。

类似的情况我在之前的帖子 154 楼有回复,也可以参考一下:/t/522131

另:
领导下班不先走其它人就不能走或不好意思走,我不知道哪来的这个规定,我觉得这是氛围问题。
反正我一般都是最后一个走的,组员事不多就正常下班,事很多的话我就跟着一起加班处理问题。
包括如果临时有事,周六需要某一两个人加班,我也会跟着一起加班,不知道这样做算不算工贼。
2019-09-04 01:11:19 +08:00
回复了 vast0906 创建的主题 Python BaseHTTPServer 库中如何获取客户端请求 server 端的域名是什么?
@lcdtyph #11
首先我觉得你预设了楼主认为 “一定拿到真实 host ” 的需求,我没有看到楼主要求这个。
楼主问这个的原因,我猜测是因为 BaseHTTPServer 没有 self.host,让楼主有些懵如何自己获取。

相对应的,例如 flask 有 flask.Request.host,django 有 django.http.HttpRequest.get_host,都可以直接取。
https://flask.palletsprojects.com/en/1.1.x/api/#flask.Request.host
https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.get_host

那么他们都是怎么取的呢?我比较懒,只翻了 flask,层层追溯可以找到这里:
https://github.com/pallets/werkzeug/blob/master/src/werkzeug/wsgi.py#L145

而 django,其实上面贴的文档里已经讲了,相比直接去 host 字段,还考虑了反代的场景。


至于:ssl 卸载靠 web server,反代的时候直接把 sni 信息塞进一个 header 转发给 simplehttpserver 就行了。
不妨调研一下,想要实现这样的效果,应该怎样去具体实现,怕不是要写个 nginx 插件才行?


最后,关于 “ webserver 是可信的”,不妨看一下著名的 WebServer Nginx 是怎样处理请求的:
http://nginx.org/en/docs/http/request_processing.html

我想,你应该能看到大量的 ' “ Host ” header field ' 这样的字眼,我就不多说了。
2019-09-04 00:25:47 +08:00
回复了 vast0906 创建的主题 Python BaseHTTPServer 库中如何获取客户端请求 server 端的域名是什么?
@lcdtyph #8
一个 “恶意” 的客户端,如何做到:
让 Web Server 拿到正确的域名(从而正常分发 vhost )
却又
不让 Web Application 拿到正确的域名(从而无法取出 host 字段)

请注意:
只传递正确的 SNI,但传递错误的 host 字段,不但会欺骗 Web Application,
事实上在 Web Server 也会被欺骗,此时就已经跑到错误的 vhost 去了。

另外如果采取 SNI 的方式,你的 SSL 负载要靠 Web Server 来卸载 还是靠 SimpleHTTPServer 来卸载呢?
靠 Web Server 来卸载的话,哪儿来的 SNI 信息呢?靠 SimpleHTTPServer 卸载的话,好像不支持吧?
以及,我甚至不需要考虑恶意的客户端,对于 IE6 IE7 这种不支持 SNI 的浏览器,是不是又变成了拿不到了呢?

其实并不是:SimpleHTTPServer 没有“一定”能拿到域名的方法。
而应当是:任何的 Web Server 都没有 没有“一定”能拿到域名的方法。


在当前的环境下,我认为 HTTP 1.1 可以当做事实上的最优选择。
1 ... 187  188  189  190  191  192  193  194  195  196 ... 286  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4674 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 53ms · UTC 05:36 · PVG 13:36 · LAX 21:36 · JFK 00:36
Developed with CodeLauncher
♥ Do have faith in what you're doing.