Nginx技巧：使用try_files避免不必要的404错误
Nginx是一个高性能的开源Web 服务器 软件，它以其出色的性能和灵活的配置而受到广泛关注。在使用Nginx时，经常会遇到404错误，这是因为请求的文件或资源不存在。为了提供更好的用户体验，我们可以使用Nginx的try_files指令来避免不必要的404错误。
什么是try_files指令？
try_files指令是Nginx的一个重要指令，它用于在文件或目录不存在时进行重定向或处理。通过配置try_files指令，我们可以指定Nginx在文件或目录不存在时应该执行的操作，例如返回一个自定义的错误页面、重定向到其他页面或执行其他处理逻辑。
如何使用try_files指令避免404错误？
下面是一个使用try_files指令的示例配置：
location / {try_files $uri $uri/ /index.php?$query_string;}
在上面的配置中，$uri表示请求的URI，$uri/表示请求的URI加上一个斜杠，/index.php?$query_string表示重定向到index.php页面并将原始的查询字符串传递给它。
当Nginx接收到一个请求时，它会按照try_files指令的顺序依次尝试匹配文件或目录。如果找到了匹配的文件或目录，Nginx会直接返回它；如果找不到匹配的文件或目录，Nginx会按照try_files指令中的配置进行处理。
通过合理配置try_files指令，我们可以避免不必要的404错误。例如，当用户请求一个不存在的静态文件时，我们可以返回一个自定义的错误页面，告诉用户该文件不存在；当用户请求一个不存在的目录时，我们可以重定向到其他页面，或者执行其他处理逻辑。
示例代码
下面是一个使用try_files指令的示例代码：
server {listen 80;server_name example.com;root /var/www/html;index index.php index.html;location / {try_files $uri $uri/ /index.php?$query_string;}location ~ .php$ {fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include fastcgi_params;}}
在上面的示例代码中，我们配置了一个简单的Nginx服务器，当用户请求一个不存在的文件或目录时，Nginx会尝试匹配其他文件或目录，如果找不到匹配的文件或目录，Nginx会将请求转发给index.php页面进行处理。
总结
通过合理配置Nginx的try_files指令，我们可以避免不必要的404错误，提供更好的用户体验。使用try_files指令，我们可以返回自定义的错误页面、重定向到其他页面或执行其他处理逻辑。如果您正在使用Nginx作为Web服务器，建议您学习并使用try_files指令来优化您的网站。
香港服务器首选树叶云
树叶云是一家专业的云计算公司，提供高性能的香港服务器。作为一家领先的云计算服务提供商，树叶云的香港服务器具有稳定可靠、高性能、低延迟等优势。如果您需要香港服务器，树叶云是您的首选。
了解更多信息，请访问树叶云官网。
nginx配置文件中怎么把hostname的值赋给其它变量
Nginx 的配置文件使用的就是一门微型的编程语言，许多真实世界里的 Nginx 配置文件其实就是一个一个的小程序。 当然，是不是“图灵完全的”暂且不论，至少据我观察，它在设计上受 Perl 和 Bourne Shell 这两种语言的影响很大。 在这一点上，相比 Apache 和 Lighttpd 等其他 Web 服务器的配置记法，不能不说算是 Nginx 的一大特色了。 既然是编程语言，一般也就少不了“变量”这种东西（当然，Haskell 这样奇怪的函数式语言除外了）。 熟悉 Perl、Bourne Shell、C/C++ 等命令式编程语言的朋友肯定知道，变量说白了就是存放“值”的容器。 而所谓“值”，在许多编程语言里，既可以是 3.14 这样的数值，也可以是 hello world 这样的字符串，甚至可以是像数组、哈希表这样的复杂数据结构。 然而，在 Nginx 配置中，变量只能存放一种类型的值，因为也只存在一种类型的值，那就是字符串。 比如我们的 文件中有下面这一行配置：set $a hello world;我们使用了标准 ngx_rewrite 模块的 set 配置指令对变量 $a 进行了赋值操作。 特别地，我们把字符串 hello world 赋给了它。 我们看到，Nginx 变量名前面有一个 $ 符号，这是记法上的要求。 所有的 Nginx 变量在 Nginx 配置文件中引用时都须带上 $ 前缀。 这种表示方法和 Perl、PHP 这些语言是相似的。 虽然 $ 这样的变量前缀修饰会让正统的 Java 和 C# 程序员不舒服，但这种表示方法的好处也是显而易见的，那就是可以直接把变量嵌入到字符串常量中以构造出新的字符串：set $a hello;set $b $a, $a;这里我们通过已有的 Nginx 变量 $a 的值，来构造变量 $b 的值，于是这两条指令顺序执行完之后，$a 的值是 hello，而 $b 的值则是 hello, hello. 这种技术在 Perl 世界里被称为“变量插值”（variable interpolation），它让专门的字符串拼接运算符变得不再那么必要。 我们在这里也不妨采用此术语。 我们来看一个比较完整的配置示例：server {listen 8080;location /test {set $foo hello;echo foo: $foo;}}这个例子省略了 配置文件中最外围的 http 配置块以及 events 配置块。 使用 cURL 这个 HTTP 客户端在命令行上请求这个 /test 接口，我们可以得到$ curlhello这里我们使用第三方 ngx_echo 模块的 echo 配置指令将 $foo 变量的值作为当前请求的响应体输出。 我们看到，echo 配置指令的参数也支持“变量插值”。 不过，需要说明的是，并非所有的配置指令都支持“变量插值”。 事实上，指令参数是否允许“变量插值”，取决于该指令的实现模块。 如果我们想通过 echo 指令直接输出含有“美元符”（$）的字符串，那么有没有办法把特殊的 $ 字符给转义掉呢？答案是否定的（至少到目前最新的 Nginx 稳定版 1.0.10）。 不过幸运的是，我们可以绕过这个限制，比如通过不支持“变量插值”的模块配置指令专门构造出取值为 $ 的 Nginx 变量，然后再在 echo 中使用这个变量。 看下面这个例子：geo $dollar {default $;}server {listen 8080;location /test {echo This is a dollar sign: $dollar;}}测试结果如下：$ curlis a dollar sign: $这里用到了标准模块 ngx_geo 提供的配置指令 geo 来为变量 $dollar 赋予字符串 $，这样我们在下面需要使用美元符的地方，就直接引用我们的 $dollar 变量就可以了。 其实 ngx_geo 模块最常规的用法是根据客户端的 IP 地址对指定的 Nginx 变量进行赋值，这里只是借用它以便“无条件地”对我们的 $dollar 变量赋予“美元符”这个值。 在“变量插值”的上下文中，还有一种特殊情况，即当引用的变量名之后紧跟着变量名的构成字符时（比如后跟字母、数字以及下划线），我们就需要使用特别的记法来消除歧义，例如：server {listen 8080;location /test {set $first hello ;echo ${first}world;}}这里，我们在 echo 配置指令的参数值中引用变量 $first 的时候，后面紧跟着 world 这个单词，所以如果直接写作 $firstworld 则 Nginx “变量插值”计算引擎会将之识别为引用了变量 $firstworld. 为了解决这个难题，Nginx 的字符串记法支持使用花括号在 $ 之后把变量名围起来，比如这里的 ${first}. 上面这个例子的输出是：$ curlworldset 指令（以及前面提到的 geo 指令）不仅有赋值的功能，它还有创建 Nginx 变量的副作用，即当作为赋值对象的变量尚不存在时，它会自动创建该变量。 比如在上面这个例子中，如果 $a 这个变量尚未创建，则 set 指令会自动创建 $a 这个用户变量。 如果我们不创建就直接使用它的值，则会报错。 例如server {listen 8080;location /bad {echo $foo;}}此时 Nginx 服务器会拒绝加载配置:1[emerg] unknown foo variable是的，我们甚至都无法启动服务！有趣的是，Nginx 变量的创建和赋值操作发生在全然不同的时间阶段。 Nginx 变量的创建只能发生在 Nginx 配置加载的时候，或者说 Nginx 启动的时候；而赋值操作则只会发生在请求实际处理的时候。 这意味着不创建而直接使用变量会导致启动失败，同时也意味着我们无法在请求处理时动态地创建新的 Nginx 变量。 Nginx 变量一旦创建，其变量名的可见范围就是整个 Nginx 配置，甚至可以跨越不同虚拟主机的 server 配置块。 我们来看一个例子：server {listen 8080;location /foo {echo foo = [$foo];}location /bar {set $foo 32;echo foo = [$foo];}}这里我们在 location /bar 中用 set 指令创建了变量 $foo，于是在整个配置文件中这个变量都是可见的，因此我们可以在 location /foo 中直接引用这个变量而不用担心 Nginx 会报错。 下面是在命令行上用 curl 工具访问这两个接口的结果：$ curl= []$ curl= [32]$ curl= []从这个例子我们可以看到，set 指令因为是在 location /bar 中使用的，所以赋值操作只会在访问 /bar 的请求中执行。 而请求 /foo 接口时，我们总是得到空的 $foo 值，因为用户变量未赋值就输出的话，得到的便是空字符串。 从这个例子我们可以窥见的另一个重要特性是，Nginx 变量名的可见范围虽然是整个配置，但每个请求都有所有变量的独立副本，或者说都有各变量用来存放值的容器的独立副本，彼此互不干扰。 比如前面我们请求了 /bar 接口后，$foo 变量被赋予了值 32，但它丝毫不会影响后续对 /foo 接口的请求所对应的 $foo 值（它仍然是空的！），因为各个请求都有自己独立的 $foo 变量的副本。 对于 Nginx 新手来说，最常见的错误之一，就是将 Nginx 变量理解成某种在请求之间全局共享的东西，或者说“全局变量”。 而事实上，Nginx 变量的生命期是不可能跨越请求边界的。
C/C++异常处理
这个很难说清楚，基本上就是： try { //....... throw ... } catch（） { //...... } 也就是一个程序段要抛出一个异常，然后要写一个相应的catch代码来捕获这个相应的异常。抛出的异常类型要与紧跟在try代码块之后的catch代码的形参相对应。一个try程序块之后可以紧跟多个catch程序块，但必须保证在try程序块中得抛出一个与之后catch代码的形参列表所匹配的异常类型。 比如说你在try代码块内抛出一个int 类型的异常，那么在紧跟其后的catch代码块的形参列表中就应该是一个int类型。最后catch代码块在捕获了这个抛出的异常后就可以对这个异常做处理，同时也可以再抛出一个异常。 下面给一个我为楼主写的例子，楼主可以看一下。这是一个求二次方程两个根的问题，里面就用到了异常的抛出与捕获。 #include
Spring有什么好处？
在SSH框假中spring充当了管理容器的角色。 我们都知道Hibernate用来做持久层，因 为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。 Struts是用来做应用层的，他它负责调用业务逻辑serivce层。 所以SSH框架的流程大致 是：Jsp页面----Struts------Service（业务逻辑处理类）---Hibernate（左到右）struts 负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的 依赖和强，属于耦合。 这时，使用spring框架就起到了控制Action对象（Strus中的）和 Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正 是用在此处。 Spring的Ioc（控制反转和依赖注入） 控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直 接操控。 依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注 入到组件之中。 从上面我们不难看出：从头到尾Action仅仅是充当了Service的控制工具，这些具体的 业务方法是怎样实现的，他根本就不会管，也不会问，他只要知道这些业务实现类所提供的 方法接口就可以了。 而在以往单独使用Struts框架的时候，所有的业务方法类的生命周期， 甚至是一些业务流程都是由Action来控制的。 层与层之间耦合性太紧密了，既降低了数据访 问的效率又使业务逻辑看起来很复杂，代码量也很多。 ，Spring容器控制所有Action对象和 业务逻辑类的生命周期，由与上层不再控制下层的生命周期，层与层之间实现了完全脱耦， 使程序运行起来效率更高，维护起来也方便。 使用Spring的第二个好处（AOP应用）： 事务的处理： 在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch 来完成，而在 Spring中。 Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能， 包括异常时事务回滚，操作成功时数据提交等复杂业务功能。 这都是由Spring容器来管理， 大大减少了程序员的代码量，也对事务有了很好的管理控制。 Hibernate中也有对事务的管 理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。 而Spring对 SessionFactory配置也进行了整合，不需要在通过来对 SessionaFactory进行设定。 这样的话就可以很好的利用Sping对事务管理强大功能。 避免 了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的 Try/Catch操作。 这些也就是Spring中的AOP（面向切面编程）机制很好的应用。 一方面使 开发业务逻辑更清晰、专业分工更加容易进行。 另一方面就是应用Spirng AOP隔离降低了 程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。
发表评论