最新发布 RSS Toggle Comment Threads | 键盘快捷键

• 

  jnavy pm 10:55 on 2012 年 04 月 23 日 链接地址 | 回复  

  MAC+iTerm定制目录显示颜色和提示符 

  原文：

  http://hi.baidu.com/rainfish_tju/blog/item/0f54458f849141f0513d9284.html

  折腾了许久,进展如下:
  知道该如何定制ls时各种类型文件(unix下所有的都是file..)的颜色了.
  很简单,就是在.bash_profile下加了三行.
  export CLICOLOR=1
  export LSCOLORS=Fxbxaxdxcxegedabagacad

  另外加了一行个性化提示符.
  export PS1=”\[\e[32;1m\]\u@\H \w \$ \[\e[0m\]”

  相关的文章参见:

  http://mac.linsheng.me/archives/530.html

  http://www.ibm.com/developerworks/cn/linux/l-tip-prompt/tip01/

  我来个copy

  上面这个方案虽然解决了彩色显示问题，但是还有一点不足，就是无法设置显示的颜色。比如说，我想用红色显示目录，那么这种方法是做不到的。下面我们来看看一个更好的解决方案。同样是修改~/.bash_profile文件，在文件中加入下面两行配置。

  export CLICOLOR=1

  export LSCOLORS=gxfxaxdxcxegedabagacad

  保存文件，重新运行“终端”，我们发现目录的颜色由蓝色变成了青色。

  

  配置

  那么应该怎样来配置成我喜欢的颜色呢？下面我们就来详细说一些这些配置。

  ~/.bash_profile是bash shell中当前登录用户的配置文件。bash是“终端”中默认的shell。

  alias ls=”ls -G”是给”ls -G”起了一个别名，当执行ls时，就相当于执行了ls -G。

  CLICOLOR是用来设置是否进行颜色的显示。CLI是Command Line Interface的缩写。

  LSCOLORS是用来设置当CLICOLOR被启用后，各种文件类型的颜色。LSCOLORS的值中每两个字母为一组，分别设置某个文件类型的文字颜色和背景颜色。LSCOLORS中一共11组颜色设置，按照先后顺序，分别对以下的文件类型进行设置：

  1. directory
  2. symbolic link
  3. socket
  4. pipe
  5. executable
  6. block special
  7. character special
  8. executable with setuid bit set
  9. executable with setgid bit set
  10. directory writable to others, with sticky bit
  11. directory writable to others, without sticky bit

  LSCOLORS中，字母代表的颜色如下：

  • a 黑色
  • b 红色
  • c 绿色
  • d 棕色
  • e 蓝色
  • f 洋红色
  • g 青色
  • h 浅灰色
  • A 黑色粗体
  • B 红色粗体
  • C 绿色粗体
  • D 棕色粗体
  • E 蓝色粗体
  • F 洋红色粗体
  • G 青色粗体
  • H 浅灰色粗体
  • x 系统默认颜色

  所以，如果我们想把目录显示成红色，就可以把LSCOLORS设置为bxfxaxdxcxegedabagacad就可以了

  ——————–

  如果您很容易使 shell 提示行变得色彩绚烂且带有更多信息，为什么还要坚持用烦人的标准提示行呢？在这篇技巧中，Daniel Robbins 将说明如何获得符合您的意愿的 shell 提示行，并会说明如何动态更新 xterm 的标题栏。

  作为 Linux/UNIX 人，我们有很长的时间是在 shell 中工作，并且在许多情况下，下面这一行就是始终盯着我们的那个提示行：

  bash-2.04$

   

  如果您恰巧是超级用户 (root)，您就有权使用下面这个美丽的标示“身份”的提示行版本：

  bash-2.04#

   

  这些提示行并不是十分漂亮。这也就难怪几种 Linux 版本对默认提示行进行了升级，在其中增加了颜色和更多的信息。但是，即便您恰好有一个本身带有很好的彩色提示行的新式版本，它也不可能是完美无缺的。您或 许希望在提示行中增加或更改几种颜色，或者增加（或删除）一些信息。从头开始设计属于您自己的彩色的、经过装饰的提示行并不难。

  在 bash 下，可以通过更改 PS1 环境变量的值来设置提示行，如下所示：

  $ export PS1="> " >

   

  更改会立即生效，通过将 “export” 定义放在您的 ~/.bashrc 文件中可将这种更改固定下来。只要您愿意，PS1 可以包含任意数量的纯文本：

  $ export PS1="This is my super prompt > " This is my super prompt >

   

  尽管这很有趣，但在提示行中包含大量静态文本并不是特别有用。大多数定制的提示行包含诸如用户名、工作目录或主机名之类的信息。这些花絮信息可以帮助您在 shell 世界中遨游。例如，下面的提示行将显示您的用户名和主机名：

  $ export PS1="\u@\H > " drobbins@freebox >

   

  这个提示行对于那些以多个不同名称的帐户登录多台机器的人尤为有用，因为它可以提醒您：您目前在哪台机器上操作，拥有什么权限。

  在上面的示例中，我们使用了专用的用反斜杠转义的字符序列，藉此通知 bash 将用户名和主机名插入提示行中，当这些转义字符序列出现在 PS1 变量中时，bash 就会用特定的值替换它们。我们使用了序列 “\u”（表示用户名）和 “\H”（表示主机名的第一部分）。下面是 bash 可识别的全部专用序列的完整列表（您可以在 bash man page 的 “PROMPTING” 部分找到这个列表）：

  序列	说明
  \a	ASCII 响铃字符（也可以键入 \007）
  \d	“Wed Sep 06″ 格式的日期
  \e	ASCII 转义字符（也可以键入 \033）
  \h	主机名的第一部分（如 “mybox”）
  \H	主机的全称（如 “mybox.mydomain.com”）
  \j	在此 shell 中通过按 ^Z 挂起的进程数
  \l	此 shell 的终端设备名（如 “ttyp4″）
  \n	换行符
  \r	回车符
  \s	shell 的名称（如 “bash”）
  \t	24 小时制时间（如 “23:01:01″）
  \T	12 小时制时间（如 “11:01:01″）
  \@	带有 am/pm 的 12 小时制时间
  \u	用户名
  \v	bash 的版本（如 2.04）
  \V	Bash 版本（包括补丁级别） ?/td>
  \w	当前工作目录（如 “/home/drobbins”）
  \W	当前工作目录的“基名 (basename)”（如 “drobbins”）
  \!	当前命令在历史缓冲区中的位置
  \#	命令编号（只要您键入内容，它就会在每次提示时累加）
  \$	如果您不是超级用户 (root)，则插入一个 “$”；如果您是超级用户，则显示一个 “#”
  \xxx	插入一个用三位数 xxx（用零代替未使用的数字，如 “\007″）表示的 ASCII 字符
  \\	反斜杠
  \[	这个序列应该出现在不移动光标的字符序列（如颜色转义序列）之前。它使 bash 能够正确计算自动换行。
  \]	这个序列应该出现在非打印字符序列之后。

  这样，您已经知道了 bash 中用反斜杠转义的全部专用序列。请稍微演练一下这些序列，以对它们的工作方式获得一些感性认识。在您做了一些测试之后，下面开始添加颜色。

   

   

  添加颜色相当容易；第一步是设计不带颜色的提示行。然后，我们所要做的只是添加终端（而不是 bash）可识别的专用转义序列，以使它以彩色显示文本的某些部分。标准 Linux 终端和 X 终端允许您设置前景（文字）颜色和背景颜色，如果需要，还可以启用 “bold” 字符。有八种颜色可供我们选择。

  颜色是通过在 PS1 中添加专用序列来选择的 — 基本上是夹在 “\e["（转义开方括号）和 "m" 之间数字值。如果指定一个以上的数字代码，则用分号将它们分开。下面是一个颜色代码示例：

  "\e[0m"

   

  如果将数字代码指定为零，则它就会通知终端将前景、背景和加粗设置重置为它们的默认值。您可能会在在提示行结束时使用这个代码，以使您键入的文字成为非彩色的。现在，让我们看一下这些颜色代码。请注意下面的抓屏结果：
  颜色表 
  

  要使用这个表，首先请查找您要使用的颜色，然后查找对应的前景编号 (30-37) 和背景编号 (40-47)。例如，如果您喜欢黑底绿字，则可将编号分别设为 32 和 40。然后打开您的提示行定义并在其中添加适当的颜色代码。下面的定义：

  export PS1="\w> "

   

  变为：

  export PS1="\e[32;40m\w> "

   

  到现在为止，提示行尽管已经很不错了，但仍不太完美。在 bash 显示出工作目录以后，我们需要使用 "\e[0m" 序列将颜色重新设置为正常值。

  export PS1="\e[32;40m\w> \e[0m"

   

  这个定义将显示一个漂亮的绿色提示行，但我们仍需要做一些扫尾工作。我们不需要包括 "40" 这个背景颜色设置，因为它将背景设置为黑色，而黑色是默认颜色。此外，绿色还很暗；我们通过添加一个 "1" 颜色代码来修正这个问题，这将启用更亮的加粗文字。除了这个修改之外，我们还需要将全部非打印字符用专用的 bash 转义序列 "\[" 和 "\]” 括起来。这两个序列通知 bash，被括起来的字符不占用行上的任何空间，这样就使自动换行能够继续正常工作。没有这两个转义序列，尽管您有了一个非常漂亮的提示行，但是如果您键入的命令恰好到达终端的最右端，就会造成显示混乱。下面是我们最终的提示行：

  export PS1="\[\e[32;1m\]\w> \[\e[0m\]"

   

  别担心在同一个提示行中使用几种颜色，就像下面这样：

  export PS1="\[\e[36;1m\]\u@\[\e[32;1m\]\H> \[\e[0m\]"

   

  我已说明了如何在提示行中添加信息和颜色，但您还可以更进一步。您可以通过在提示行中添加专用代码来使 X 终端（如 rxvt 或 aterm）的标题栏得到动态更新。您所要做的只是将下面的序列添加到您的 PS1 提示行中：

  "\e]2;titlebar\a"

   

  只须用您希望其出现在 xterm 标题栏中的文字替换子串 “titlebar” 即可，现在已经一切就绪了！不必使用静态文字；您可以将 bash 转义序列插入标题栏中。请查看下面这个示例，它将用户名、主机名和当前工作目录显示在标题栏中，并定义了一个简短、明亮的绿色提示行：

  export PS1="\[\e]2;\u@\H \w\a\e[32;1m\]>\[\e[0m\] "

   

  这就是我在上面的抓屏结果中所用的那个提示行。我喜欢这个提示行，因为它将全部信息显示在标题栏上，而不是显示在终端上，终端对一行可以显示多少字符有限制。顺便提一句，确保用 “\[" 和 "\]” 将您的标题栏序列括起来（因为就终端而言，这个序列是非打印序列）。将大量信息放在标题栏中的问题是，如果您使用非图形终端（如系统控制台），则看不到这些信息。为了解决这个问题，可以在您的 .bashrc 中添加以下几行：

  if [ "$TERM" = "linux" ] then #we're on the system console or maybe telnetting in export PS1="\[\e[32;1m\]\u@\H > \[\e[0m\]" else #we're not on the console, assume an xterm export PS1="\[\e]2;\u@\H \w\a\e[32;1m\]>\[\e[0m\] " fi

   

  这个 bash 条件语句将根据当前的终端设置动态设置提示行。为了获得一致性，您一定希望配置您的 ~/.bash_profile，以便它在启动时搜索 (source) 您的 ~/.bashrc。确保您的 ~/.bash_profile 文件中有以下这样一行：

  source ~/.bashrc

   

  这样，无论您开启一个登录 shell 还是一个非登录 shell，都会获得同样的提示行。

  好了，您已掌握了提示行魔术。现在尽情享受一下，制作一个漂亮的彩色提示行吧！

   

  回复 取消回复

  必填项已用 * 标注

  姓名 *

  电子邮件 *

  站点

  

  

  
  

  验证码 *

  

• 

  jnavy am 7:03 on 2012 年 04 月 22 日 链接地址 | 回复  

  restart 

  前几天升级了wordpress，没想到被ixwebhosting给封了，说有个php文件占用资源太多，无奈之下，删掉了，网站终于又起来了，现在不敢升新版了。

   
• 

  jnavy pm 1:58 on 2012 年 03 月 19 日 链接地址 | 回复  

  nginx中handler的处理(一)转 

  原文：

  http://simohayha.iteye.com/blog/670326

  nginx中的处理一个http的请求分为了8个phase,分别是下面几个阶段.

  其中特别要注意就是几个rewrite阶段。

  Java代码  

  1. typedef enum {
  2. //读取请求phase
  3.     NGX_HTTP_POST_READ_PHASE = 0,
  4. //接下来就是开始处理
  6. //这个阶段主要是处理全局的(server block)的rewrite。
  7.     NGX_HTTP_SERVER_REWRITE_PHASE,
  8. //这个阶段主要是通过uri来查找对应的location。然后将uri和location的数据关联起来
  9.     NGX_HTTP_FIND_CONFIG_PHASE,
  10. //这个主要处理location的rewrite。
  11.     NGX_HTTP_REWRITE_PHASE,
  12. //post rewrite，这个主要是进行一些校验以及收尾工作，以便于交给后面的模块。
  13.     NGX_HTTP_POST_REWRITE_PHASE,
  14. //比如流控这种类型的access就放在这个phase，也就是说它主要是进行一些比较粗粒度的access。
  15.     NGX_HTTP_PREACCESS_PHASE,
  17. //这个比如存取控制，权限验证就放在这个phase，一般来说处理动作是交给下面的模块做的.这个主要是做一些细粒度的access。
  18.     NGX_HTTP_ACCESS_PHASE,
  19. //一般来说当上面的access模块得到access_code之后就会由这个模块根据access_code来进行操作
  20.     NGX_HTTP_POST_ACCESS_PHASE,
  22. //try_file模块，也就是对应配置文件中的try_files指令。
  23.     NGX_HTTP_TRY_FILES_PHASE,
  24. //内容处理模块，我们一般的handle都是处于这个模块
  25.     NGX_HTTP_CONTENT_PHASE,
  26. //log模块
  27.     NGX_HTTP_LOG_PHASE
  28. } ngx_http_phases;

  这里要注意的就是这几个phase的执行是严格按照顺序的，也就是NGX_HTTP_POST_READ_PHASE是第一个，而LOG_PHASE是最后一个。只有一个特殊那就是FIND_CONFIG_PHASE，这个的话，有可能会在后面的rewrite phase再来调用这个phase。

  这里handler的结构是这样的，在ngx_http_core_main_conf_t中会有一个包含了ngx_http_phase_t结构的数组，而ngx_http_phase_t包含了一个动态数组，也就是说每一个phase都有一个handler数组。

  Java代码  

  1. typedef struct {
  2. ………………………………………………………….
  3.     ngx_http_phase_t           phases[NGX_HTTP_LOG_PHASE + 1];
  4. } ngx_http_core_main_conf_t;
  6. typedef struct {
  7. //每个phase都会有一个handler数组。
  8.     ngx_array_t                handlers;
  9. } ngx_http_phase_t;

  然后每个handler数组的元素都是一个hanler函数。

  Java代码  

  1. typedef ngx_int_t (*ngx_http_handler_pt)(ngx_http_request_t *r);

  也就是我们写handler的时候注册的handler函数。

  ok，接下来我们来看phase的初始化，初始化函数是ngx_http_init_phase_handlers。

  在看phase初始化之前，我们先来看一个叫做ngx_http_phase_handler_s的结构体，这个结构体是保存在ngx_http_core_main_conf_t 中的，最终我们通过上面所讲的phases注册的handler链会被转换为ngx_http_phase_handler_s，然后保存在ngx_http_core_main_conf_t的phase_engine中。而后面对handler的调用处理都是使用ngx_http_phase_handler_s。

  这个结构体是每个handler都会有一个的，也就是说所有的phase handler最终都会链接到一个大的数组中，这个大数组就是ngx_http_phase_engine_t的handlers域。

  Java代码  

  1. typedef struct {
  2. //所有的hanler都会在这个数组中.
  3.     ngx_http_phase_handler_t  *handlers;
  4.     ngx_uint_t                 server_rewrite_index;
  5.     ngx_uint_t                 location_rewrite_index;
  6. } ngx_http_phase_engine_t;

  然后我们来看它的每个域的含义。

  checker  所有处于相同phase的handler的check都是相同的，每个phase的handler的调用都是在check中的，也就是check进行一些校验，结果判断等等操作。

  handler就是对应的handler处理函数

  ngxt 表示了下一个要执行的handler(也就是ngx_http_phase_handler_s)的位置,由于是数组，所以这个也就表示数组索引。而这个默认就是下一个将要执行的phase

  Java代码  

  1. struct ngx_http_phase_handler_s {
  2.     ngx_http_phase_handler_pt  checker;
  3.     ngx_http_handler_pt        handler;
  4.     ngx_uint_t                 next;
  5. };

  来看函数的实现，其实功能很简单，就是初始化ngx_http_phase_handler_s，将我们注册的handler都链接到这个数组中，然后还有一些校验等。

  这里要注意有些phase的话只会有一个handler，比如CONFIG_PHASE，下面的代码中我们会详细看到。

  Java代码  

  1. static ngx_int_t
  2. ngx_http_init_phase_handlers(ngx_conf_t *cf, ngx_http_core_main_conf_t *cmcf)
  3. {
  4.     ngx_int_t                   j;
  5.     ngx_uint_t                  i, n;
  6.     ngx_uint_t                  find_config_index, use_rewrite, use_access;
  7.     ngx_http_handler_pt        *h;
  8. //最终的handler数组
  9.     ngx_http_phase_handler_t   *ph;
  10.     ngx_http_phase_handler_pt   checker;
  12.     cmcf->phase_engine.server_rewrite_index = (ngx_uint_t) -1;
  13.     cmcf->phase_engine.location_rewrite_index = (ngx_uint_t) -1;
  14.     find_config_index = 0;
  15. //是否有使用rewrite以及access。
  16.     use_rewrite = cmcf->phases[NGX_HTTP_REWRITE_PHASE].handlers.nelts ? 1 : 0;
  17.     use_access = cmcf->phases[NGX_HTTP_ACCESS_PHASE].handlers.nelts ? 1 : 0;
  19. //开始计算handler 数组的大小
  20.     n = use_rewrite + use_access + cmcf->try_files + 1 /* find config phase */;
  21.     for (i = 0; i < NGX_HTTP_LOG_PHASE; i++) {
  22.         n += cmcf->phases[i].handlers.nelts;
  23.     }
  25. //数组分配内存
  26.     ph = ngx_pcalloc(cf->pool,
  27.                      n * sizeof(ngx_http_phase_handler_t) + sizeof(void *));
  28.     if (ph == NULL) {
  29.         return NGX_ERROR;
  30.     }
  32. //handler数组放到handlers里面。
  33.     cmcf->phase_engine.handlers = ph;
  34. //n表示下一个phase的索引。
  35.     n = 0;
  37. //开始遍历phase handler.这里是一个phase一个phase的遍历。
  38.     for (i = 0; i < NGX_HTTP_LOG_PHASE; i++) {
  39. //取出对应的handler处理函数
  40.         h = cmcf->phases[i].handlers.elts;
  41. //根据不同的phase来处理
  42.         switch (i) {
  43. //server重写phase（也就是内部重定向phase)
  44.         case NGX_HTTP_SERVER_REWRITE_PHASE:
  45. //如果有定义重写规则则设置重写handler的索引n.
  46.             if (cmcf->phase_engine.server_rewrite_index == (ngx_uint_t) -1) {
  47.                 cmcf->phase_engine.server_rewrite_index = n;
  48.             }
  49. //赋值checker
  50.             checker = ngx_http_core_generic_phase;
  52.             break;
  53. //config phase只有一个.这里设置 find_config_index，是因为当我们rewrite之后的url就必须重新挂载location的一些结构，因此就需要再次进入这个phase
  54.         case NGX_HTTP_FIND_CONFIG_PHASE:
  55.             find_config_index = n;
  56. //自己的checker
  57.             ph->checker = ngx_http_core_find_config_phase;
  58.             n++;
  59.             ph++;
  61.             continue;
  63. //rewrite phase
  64.         case NGX_HTTP_REWRITE_PHASE:
  65.             if (cmcf->phase_engine.location_rewrite_index == (ngx_uint_t) -1) {
  66.                 cmcf->phase_engine.location_rewrite_index = n;
  67.             }
  68. //共用的checker
  69.             checker = ngx_http_core_generic_phase;
  71.             break;
  73.         case NGX_HTTP_POST_REWRITE_PHASE:
  74. //如果有使用rewrite则给它的checker赋值
  75.             if (use_rewrite) {
  76.                 ph->checker = ngx_http_core_post_rewrite_phase;
  77. //注意它的next就是find_config phase,也就是说需要重新挂载location的数据。
  78.                 ph->next = find_config_index;
  79.                 n++;
  80.                 ph++;
  81.             }
  83.             continue;
  85.         case NGX_HTTP_ACCESS_PHASE:
  86.             checker = ngx_http_core_access_phase;
  87.             n++;
  88.             break;
  90.         case NGX_HTTP_POST_ACCESS_PHASE:
  91.             if (use_access) {
  92.                 ph->checker = ngx_http_core_post_access_phase;
  93.                 ph->next = n;
  94.                 ph++;
  95.             }
  96.             continue;
  98.         case NGX_HTTP_TRY_FILES_PHASE:
  99.             if (cmcf->try_files) {
  100.                 ph->checker = ngx_http_core_try_files_phase;
  101.                 n++;
  102.                 ph++;
  103.             }
  105.             continue;
  107.         case NGX_HTTP_CONTENT_PHASE:
  108.             checker = ngx_http_core_content_phase;
  109.             break;
  111.         default:
  112.             checker = ngx_http_core_generic_phase;
  113.         }
  115. //这里n刚好就是下一个phase的其实索引
  116.         n += cmcf->phases[i].handlers.nelts;
  118. //开始遍历当前的phase的handler。
  119.         for (j = cmcf->phases[i].handlers.nelts - 1; j >=0; j–) {
  120.             ph->checker = checker;
  121. //每个的handler就是注册的时候的回掉函数
  122.             ph->handler = h[j];
  123. //next为下一个phase的索引
  124.             ph->next = n;
  125. //下一个handler
  126.             ph++;
  127.         }
  128.     }
  130.     return NGX_OK;
  131. }

  这里需要注意就是只有下面这几个phase会有多个handler，剩余的都是只有一个handler的。

  Java代码  

  1. NGX_HTTP_POST_READ_PHASE
  2.     NGX_HTTP_SERVER_REWRITE_PHASE,
  3.     NGX_HTTP_REWRITE_PHASE,
  4.     NGX_HTTP_PREACCESS_PHASE,
  5.     NGX_HTTP_ACCESS_PHASE,
  6.     NGX_HTTP_CONTENT_PHASE,
  7.     NGX_HTTP_LOG_PHASE

  接下来我们来看phase的启动。

  phase的启动是在ngx_http_core_run_phases这个函数中的，这个函数会遍历所有phase然后调用他们的checker来进行处理，也就是说错误，返回代码的控制什么的都是由各自的checker做的。而所有的checker的返回值都是一样的。

  Java代码  

  1. void
  2. ngx_http_core_run_phases(ngx_http_request_t *r)
  3. {
  4.     ngx_int_t                   rc;
  5.     ngx_http_phase_handler_t   *ph;
  6.     ngx_http_core_main_conf_t  *cmcf;
  8.     cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);
  10.     ph = cmcf->phase_engine.handlers;
  12.     while (ph[r->phase_handler].checker) {
  14. //调用checker
  15.         rc = ph[r->phase_handler].checker(r, &ph[r->phase_handler]);
  16. //如果有一个checker返回OK，则后面的phase就不会处理的。
  17.         if (rc == NGX_OK) {
  18.             return;
  19.         }
  20.     }
  21. }
   
• 

  jnavy pm 1:57 on 2012 年 03 月 19 日 链接地址 | 回复  

  Method Definitions(转) 

  http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

  9 Method Definitions

  The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.

  The Host request-header field (section 14.23) MUST accompany all HTTP/1.1 requests.

  9.1 Safe and Idempotent Methods

  9.1.1 Safe Methods

  Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

  In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

  Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

  9.1.2 Idempotent Methods

  Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

  However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.

  A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).

  9.2 OPTIONS

  The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

  Responses to this method are not cacheable.

  If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.

  If the Request-URI is an asterisk (“*”), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server’s communication options typically depend on the resource, the “*” request is only useful as a “ping” or “no-op” type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

  If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.

  A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a

  body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of “0″.

  The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero (“0″), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.

  9.3 GET

  The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

  The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

  The semantics of the GET method change to a “partial GET” if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

  The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.

  See section 15.1.3 for security considerations when used for forms.

  9.4 HEAD

  The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

  The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

  9.5 POST

  The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

        - Annotation of existing resources;

        - Posting a message to a bulletin board, newsgroup, mailing list,
          or similar group of articles;

        - Providing a block of data, such as the result of submitting a
          form, to a data-handling process;

        - Extending a database through an append operation.

  The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

  The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

  If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

  Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

  POST requests MUST obey the message transmission requirements set out in section 8.2.

  See section 15.1.3 for security considerations.

  9.6 PUT

  The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

  If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

  The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

  it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

  A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying “the current version” which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

  HTTP/1.1 does not define how a PUT method affects the state of an origin server.

  PUT requests MUST obey the message transmission requirements set out in section 8.2.

  Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

  9.7 DELETE

  The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

  A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

  If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

  9.8 TRACE

  The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the

  origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

  TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

  If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of “message/http”. Responses to this method MUST NOT be cached.

  9.9 CONNECT

  This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

   
• 

  jnavy pm 12:48 on 2012 年 03 月 19 日 链接地址 | 回复  

  HttpTunnel技术介绍（转） 

  原文链接：

  http://www.wuzesheng.com/?p=2168

   

  1. 概述

  HttpTuunnel(也叫Http隧道，Http穿梭），是这样一种技术: 它用HTTP协议在要通信的Client和Server建立起一条”Tunnel”，然后Client和Server之间的通信，都是在这条Tunnel的基础之上。

  HttpTunnel通常被用在受限的网络环境中，比如在NAT环境中的Client，受防火墙限制的环境中的Client等，在这样的环境中，Client不能直接连接到公网(WAN)的Server，这时候就可以通过HttpTunnel技术，来解决上述问题。
  2. 原理
  
  上图是HttpTunnel技术的基本原理，它基本的工作过程主要分为以下几个步骤：
  （1）Client向ProxyServer发送要连接到Server的请求（Http协议）
  （2）Proxy Server向实际的Server发送连接请求（Http协议）
  （3）上述两步成功后，就相当于在Client和Server之间存在了一条连通的Tunnel（如上图中的蓝色虚线所示）
  （4）后续Client和Server就可以直接进行数据的收发，协议由Client和Server自己约定，与HttpTunnel无关

  3. 实现方法
  (1) 用Http CONNECT方法的实现
  Http协议支持一种叫CONNECT的方法，在上面的原理介绍的第一个步骤中，Client告诉Proxy Server来连接Server的过程中，用的就是Http的CONNECT。下面是一个示例：
  
  注意，Http的CONNECT并不是所有的Proxy Server都实现了，所在这里选择Proxy Server的时候需要注意一下。通常所用到的Proxy Server如Squid和Nginx，Squid是支持Http CONNECT，而Nginx就是不支持的。
  (2) 不用Http CONNECT的实现
  前面也讲到了，并不是所有的Proxy Server都支持Http CONNECT方法的。这时候就可能需要做一些额外的工作。需要在Client和Proxy之间再增加一个TunnelClient, 在Server和Proxy之间再增加一个Tunnel Server，由TunnelClient/TunnelServer来完成实际的Tunnel的建立和数据的转发。具体的做法可以参考一下GNU HttpTunnel（http://www.nocrew.org/software/httptunnel.html ）。

   
• 

  jnavy pm 5:07 on 2011 年 12 月 31 日 链接地址 | 回复  

  诸葛亮＜戒子篇＞ 

  夫君子之行，静以修身，俭以养德。非淡泊无以明志，非宁静无以致远。

  夫学须静也，才须学也，非学无以广才，非志无以成学。淫慢则不能励精，险躁则不能治性。

  年与时驰，意与日去，遂成枯落，多不接世，悲守穷庐，将复何及！

   
• 

  jnavy pm 12:05 on 2011 年 12 月 08 日 链接地址 | 回复  

  mysqldump(转) 

  原文：http://hi.baidu.com/aifang9999/blog/item/3c8c5e094eb7f7a92eddd48f.html

  导出：mysqldump -u root -p –default-character-set=gbk ebroad >ebroad2008_06_22_10_54.sql 导入：登陆mysql，选择数据库，输入source ebroad2008_06_22_10_54.sql这个命令   mysqldump -uroot -pblip –default-character-set=gbk ebroad >ebroad06-24.sql       在MySQL数据库中导出整个数据库： 1.导出整个数据库 mysqldump -u 用户名 -p 数据库名 > 导出的文件名 mysqldump -u wcnc -p smgp_apps_wcnc > wcnc.sql 2.导出一个表 mysqldump -u 用户名 -p 数据库名 表名> 导出的文件名 mysqldump -u wcnc -p smgp_apps_wcnc users> wcnc_users.sql 3.导出一个数据库结构 mysqldump -u wcnc -p -d –add-drop-table smgp_apps_wcnc >d:wcnc_db.sql -d 没有数据 –add-drop-table 在每个create语句之前增加一个drop table 4.导入数据库 常用source 命令 进入mysql数据库控制台， 如mysql -u root -p mysql>use 数据库 然后使用source命令，后面参数为脚本文件(如这里用到的.sql) mysql>source d:wcnc_db.sql ============= mysql只导出数据或者只导出表结构的语句 只导出表结构 mysqldump -uroot -p123456 -h192.168.1.11 -d   –default-character-set=utf8 test >sql.sql 只导出数据 mysqldump -uroot -p123456 -h192.168.1.11 -t   –default-character-set=utf8 test >sql.sql

   
• 

  jnavy pm 9:53 on 2011 年 11 月 30 日 链接地址 | 回复  

  在Linux下使用vim配合xxd查看并编辑二进制文件（转） 

  url:

  http://www.cnblogs.com/killkill/archive/2010/06/23/1763785.html

  通常来说文件分为文本和二进制文件两大类，文本文件的编辑很容易，Windows下的notepad、UltraEdit都很好用，二进制文件的编辑在Windows下也有很多工具，UltraEdit也不错，但是Linux下呢？今天终于发现了一个好方法，但是最终出处找不到了。

   

  首先创建一个二进制文件：

  1	[oracle@logserver tmp]$ echo -n "ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz" >test.bin

  2	[oracle@logserver tmp]$ cat test.bin

  3	ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz[oracle@logserver tmp]$

  注意echo 一定要跟上 -n 选项，否则会被自动加上一个换行行，再用vim打开 test.bin

  1	[oracle@logserver tmp]$ vim -b test.bin

  vim 的 -b 选项是告诉 vim 打开的是一个二进制文件，不指定的话，会在后面加上 0x0a ，即一个换行符。

  在命令模式下键入：

  1

  :%!xxd

  

  如果 vim 后面没有加 -b 选项就会出现可恶的 0x0a：

  

  如果有 -b 选项就不会有这种情况：

  

  然后进入编辑模式改，改就是了，我将A、B对应的41、42改成61、62，将a、b对应的61、62改成41、42。

  

  回到命令模式输入：

  1

  :%!xxd -r

  

  此时可以发现AB和ab的位置互换了。

  

  最后在命令模式中输入 :wq 保存退出即可。

   
• 

  jnavy pm 4:27 on 2011 年 11 月 22 日 链接地址 | 回复  

  Linux下查看进程打开的文件句柄数 

  在Linux下，我们使用ulimit -n 命令可以看到单个进程能够打开的最大文件句柄数量(socket连接也算在里面)。系统默认值1024。

  对于一般的应用来说(象Apache、系统进程)1024完全足够使用。但是如何象squid、mysql、java等单进程处理大量请求的应用来说就有点捉襟见肘了。如果单个进程打开的文件句柄数量超过了系统定义的值，就会提到“too many files open”的错误提示。如何知道当前进程打开了多少个文件句柄呢？下面一段小脚本可以帮你查看： /user/sbin/lsof

  1. lsof -n |awk ’{print $2}’|sort|uniq -c |sort -nr|more

  在系统访问高峰时间以root用户执行上面的脚本，可能出现的结果如下：

  1. # lsof -n|awk ’{print $2}’|sort|uniq -c |sort -nr|more
  2. 131 24204
  3. 57 24244
  4. 57 24231
  5. 56 24264

  其中第一行是打开的文件句柄数量，第二行是进程号。得到进程号后，我们可以通过ps命令得到进程的详细内容。

  1. ps -aef|grep 24204
  2. mysql    24204 24162 99 16:15 ?        00:24:25 /usr/sbin/mysqld

  哦，原来是mysql进程打开最多文件句柄数量。但是他目前只打开了131个文件句柄数量，远远底于系统默认值1024。

  但是如果系统并发特别大，尤其是squid服务器，很有可能会超过1024。这时候就必须要调整系统参数，以适应应用变化。Linux有硬性限制和软性限制。可以通过ulimit来设定这两个参数。方法如下，以root用户运行以下命令：

  1. ulimit -HSn 4096

  以上命令中，H指定了硬性大小，S指定了软性大小，n表示设定单个进程最大的打开文件句柄数量。个人觉得最好不要超过4096，毕竟打开的文件句柄数越多响应时间肯定会越慢。设定句柄数量后，系统重启后，又会恢复默认值。如果想永久保存下来，可以修改.bash_profile文件，可以修改 /etc/profile 把上面命令加到最后。(findsun提出的办法比较合理)

   

   
• 

  jnavy pm 3:54 on 2011 年 11 月 19 日 链接地址 | 回复  

  eaccelerator （转） 

  来自百度百科：http://baike.baidu.com/view/1376127.htm

  eAccelerator

  目录

  加速器

  安装和配置

  验证

  编辑本段加速器

  eAccelerator是一个自由开放源码php加速器，优化和动态内容缓存，提高了php脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。 它还有对脚本起优化作用，以加快其执行效率。使您的PHP程序代码执效率能提高1-10倍；

  编辑本段安装和配置

  首先您要安装好PHP，然后再来编译安装 eaccelerator，过程如下。我们从官方下的版本是 eaccelerator-0.9.5.2.tar.bz2　　编译安装； # tar xvf eaccelerator-0.9.5.2.tar.bz2　　# cd cd eaccelerator-0.9.5.2　　# export PHP_PREFIX=”/usr”　　# $PHP_PREFIX/bin/phpize　　# ./configure \　　–enable-eaccelerator=shared \　　–with-php-config=$PHP_PREFIX/bin/php-config　　# make　　# make install　　注：通过export 来设置php所在的安装路径变量，我的PHP是安装在/usr目录下，系统用Slackware 12.0。其它系统如果默认安装也大体差不多；如果不一样，就自己指定一下；　　完成安装后，eaccelerator.so模块位于 /usr/lib/php/extensions目录中，您的系统如果和我不一样，您自己应该安装在哪了；　　# echo “/usr/lib/php/extensions” &gt; /etc/ld.so.conf　　# ldconfig　　注：更新动态链接库地址；　　修改配置文件； 我们首先要修改；php.ini，然后重启Apache；　　在php.ini文件中，加入；　　zend_extension=”/usr/lib/php/extensions/eaccelerator.so” 注：模块的具体位置；　　eaccelerator.shm_size=”16″ 注：共享内存大小；　　eaccelerator.cache_dir=”/home/eaccelerator” 注：缓存目录；　　eaccelerator.enable=”1″　　eaccelerator.optimizer=”1″　　eaccelerator.check_mtime=”1″　　eaccelerator.debug=”0″　　eaccelerator.filter=”"　　eaccelerator.shm_max=”0″　　eaccelerator.shm_ttl=”0″　　eaccelerator.shm_prune_period=”0″　　eaccelerator.shm_only=”0″　　eaccelerator.compress=”1″　　eaccelerator.compress_level=”9″　　注：其中，模块的具体位置必须正确，以您的系统为准；共享内存大小可以自己调整，感觉16M还是可以的，根据服务器的情况，你自己调一下。缓存目录可以自己指定，我们在这里指定的是 /home目录上的 eaccelerator 目录，如果没有，自己创建一个；权限是0777；　　以上的配置是把 eaccelerator 做为 Zend 的扩展模块来编译的办法。如果您的PHP是用安装模式编译的，要把 zend_extension改为zend_extension_ts 。　　如果您是把 eaccelerator 做为 PHP的一个扩展，要用下面的配置 ；　　extension=”eaccelerator.so”　　eaccelerator.shm_size=”16″　　eaccelerator.cache_dir=”/home/eaccelerator”　　eaccelerator.enable=”1″　　eaccelerator.optimizer=”1″　　eaccelerator.check_mtime=”1″　　是不是生效了，您要查看 /home/eaccelerator 目录中，当Apache服务器启动了，你随便点几个页面，如果在这个目录中，出现文件了。那就是生效了。如果没任何文件，就要找原因了 ……　　这两个配置文件，是不是管用。要你自己根据情况来修改。　　# mkdir /home/eaccelerator　　# chmod 777 /home/eaccelerator　　注：创建缓存目录池，权限是777

  编辑本段验证

  等这一切完成后，就要重启Apache服务器，如果没弹出什么错误，大多是正确的。查看一下缓存池，点几个页面，就知道是不是管用了。好像是比较简单。　　验证安装是否完成（两种方法）　　1、打开命令行窗口，进入PHP安装目录，执行命令php -v，并查看命令结果。　　E:\php >php.exe -v　　PHP 5.2.10 (cli) (built: Jun 17 2009 16:16:57)　　Copyright (c) 1997-2009 The PHP Group　　Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies　　with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator　　with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technol　　ogies　　with Zend Optimizer v3.3.0, Copyright (c) 1998-2007, by Zend Technologies　　则配置正确。　　2、创建一个php文件，内容如下：　　<?php　　phpinfo();　　?>　　启动PHP并访问该网页，查看其中的Zend Engine部分的信息，应该与上边命令行的结果一样，则配置正确。