一个看似简单的404背后：3天调试nginx X-Accel-Redirect的血泪史

前言

这是一个关于调试的真实故事。一个看似简单的图片服务404问题，最终花费了3天时间才找到根本原因。问题的表象很简单，但背后涉及到Django图片处理、nginx内部重定向、文件系统符号链接以及nginx location优先级等多个技术点的交互。

这个调试过程充分展示了系统性问题排查的重要性，以及当多个技术组件交互时可能产生的复杂性。

问题现象

初始症状

在Django图片处理系统中，发现了一个奇怪的现象：

• AVIF请求：Accept: image/avif → 200 OK ✅
• JPEG请求：Accept: text/html → 404 Not Found ❌

同一张图片，仅仅因为客户端Accept头不同，就产生了完全不同的响应结果。

具体表现

# 支持AVIF的请求
curl -H "Accept: image/avif" "http://localhost:8500/static/images/test.jpg"
# 返回: 200 OK，成功转换为AVIF格式

# 普通浏览器请求
curl -H "Accept: text/html" "http://localhost:8500/static/images/test.jpg"  
# 返回: 404 Not Found

继续阅读

Django项目的多语言支持

引用

https://testdriven.io/blog/multiple-languages-in-django/

Django是一个非常流行和强大的Python Web框架，它提供了很多内置的功能，让开发者可以快速地构建高性能、安全、可扩展的网站。其中一个功能就是国际化和本地化，也就是让网站能够根据用户的语言和地区偏好，显示不同的内容和格式。这样，网站就可以覆盖更多的用户群体，提高用户体验和满意度。

在这篇博客中，我将介绍如何使用Django的国际化和本地化功能，以及一些第三方库，来实现多语言网站的开发。我将以一个简单的博客网站为例，展示如何让它支持英语、法语、西班牙语、越南语、波兰语、泰语、韩语、日语、简体中文和繁体中文这十种语言。我将分为以下几个步骤：

• 基本设置
• 模型和视图的国际化
• 模板的国际化
• URL的国际化
• 静态文件的国际化
• 语言切换
• 使用第三方库

基本设置

首先，我们需要在项目的settings.py文件中，做一些基本的设置，来启用国际化和本地化功能，以及指定支持的语言和默认语言。具体的设置如下：

    # 基本设置

    LANGUAGE_CODE = 'zh-hans' # 默认语言，这里我设置为简体中文
    #PARLER_DEFAULT_LANGUAGE_CODE = 'zh-hans' # 这是一个第三方库的设置，后面会介绍

    TIME_ZONE = 'UTC' # 时区，这里我设置为UTC，你可以根据需要修改

    USE_I18N = True # 启用国际化功能

    USE_L10N = True # 启用本地化功能

    USE_TZ = True # 启用时区支持

    # https://github.com/django/django/blob/main/django/conf/global_settings.py#L56
    LANGUAGES = ( # 指定支持的语言，这里我设置了十种语言，你可以根据需要增加或删除
        ('en', ('English')),
        ('fr', ('Français')),
        ('es', ('Español')),
        ('vi', ('Tiếng việt')),
        ('pl', ('Polskie')),
        ('th', ('ไทย')),
        ('ko', ('한국어')),
        ('ja', ('日本語')),
        ("zh-hans", ("简体中文")),
        ("zh-hant", ("繁體中文"))
    )

    LOCALE_PATHS = [ # 指定存放翻译文件的路径，这里我设置为项目根目录下的locale文件夹
        os.path.join(os.path.dirname(os.path.dirname(__file__)), "locale")
    ]

继续阅读

Django Cache Distinguish Desktop Mobile | Django缓存区分桌面版和手机端

Django Cache Distinguish Desktop Mobile

Django Cache 默认并不区分Desktop和Mobile， 但是如果Desktop 视图和mobile视图不同，这时Django Cache就会有问题，
如果某个页面先被desktop模式访问之后，页面会被缓存，但手机端再访问这个页面时，发布页面已经被缓存，所以直接返回，
但是被缓存的内容是Desktop模式，在手机端显示会有些奇怪。

引用

https://docs.djangoproject.com/zh-hans/4.0/topics/cache/
https://docs.djangoproject.com/zh-hans/4.0/topics/cache/#using-vary-headers
https://github.com/django/django/blob/main/django/utils/cache.py
https://github.com/Botir/Django-Mobile-Detector

Django-Mobile-Detector

Mobile Detector 请参考: https://github.com/Botir/Django-Mobile-Detector

使用Vary Header

Vary Header介绍: https://docs.djangoproject.com/zh-hans/4.0/topics/cache/#using-vary-headers

继续阅读

Puppeteer Headless浏览器与自动化测试

1 Headless浏览器 与 Puppeteer

1.1 Headless 浏览器

无头Chrome在Chrome 59中发布。这是在无头环境中运行Chrome浏览器的一种方式。 基本上，运行没有Chrome的Chrome！ 它将Chromium和Blink渲染引擎提供的所有现代Web平台功能引入命令行。

那么这个浏览器可以用来干嘛?

想象一下每次在发版前，测试人员都需要测试系统的功能，重复且乏味。于是你决定让程序自动测试界面上的功能。你不需要浏览器有GUI界面，想通过编程的方法来驱动浏览器进行各种操作，并且希望能在服务器端运行，这样每次发版前就可以自动测试相关功能，提高测试效率。

以上只是一个应用场景，Headless浏览器可以理解为没有GUI界面的浏览器程序。由于没有界面，所以在速度上比普通浏览器稍快，它可以在自动化测试、性能检查、获取元数据（例如爬虫）和网页截图等方面发挥用途。

1.2 Puppeteer 介绍

Puppeteer 是一个 Node 库，它提供了高级的 API 并通过 DevTools 协议来控制 Chrome(或Chromium)。通俗来说就是一个 headless chrome 浏览器 (也可以配置成有 UI 的，默认是没有的)

Puppeteer API可用于截取屏幕截图，创建PDF，导航页面以及从页面获取信息等.

Puppeteer API 官方参考链接: https://pptr.dev/, Puppeteer API 中文版参考链接: https://zhaoqize.github.io/puppeteer-api-zh_CN/

继续阅读

V2EX 半自动签到

前提

注册v2也有一年多了, 以前偶尔会上去看看, 现在是重度用户, 每天都会看好几次.

年初看到有讨论v2自动登录领金币帖子, 有很多网友也分享了自动签到脚本,

我也拷贝了其中一份, 放在服务器上每天自动签到, 一直都挺好的, 金币现在也有一万多了,

不过前不久v2登录添加了验证, 自动签到脚本失效了, 所以趁着国庆假期, 简单修改了一下脚本,

现在是半自动签到, 第一次或Cookie失效后, 都需要手动处理一下.

目前已经稳定签到10天了, 所以看看网友有需要的吗.

贴图

v2截图

继续阅读

历史上的今天 API (数据来自维基百科)

API地址:

http://history.lifetime.photo:81/api/history

参考/引用地址:

维基百科:https://zh.wikipedia.org/zh-cn/历史上的今天

IPIP5: http://www.ipip5.com/today/api.php?type=json

继续阅读