<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english">
    <title>gmane.comp.web.nginx.english</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39039"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39038"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39037"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39036"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39035"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39034"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39033"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39032"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39031"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39030"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39029"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39028"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39027"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39026"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39025"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39024"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39023"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39022"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39021"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.nginx.english/39020"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39039">
    <title>Re: Rewriting</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39039</link>
    <description>&lt;pre&gt;Hello,

http://nginx.org/en/docs/http/request_processing.html

Because in this case you need to place your rule in server block if you 
would like to be valid for all custom defined locations in your config
For example:

server
{
listen 80;

if ($remote_addr ~ '192.168.1.25')
{
return 403;
}

location /
{
...
}

location ~ \.php$
{
...
}

}

On 23.05.2013 23:11 ч., wishmaster wrote:

_______________________________________________
nginx mailing list
nginx&amp;lt; at &amp;gt;nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Bozhidara Marinchovska</dc:creator>
    <dc:date>2013-05-23T21:47:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39038">
    <title>Rewriting</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39038</link>
    <description>&lt;pre&gt;Hi,
I use opencart with nginx+php-fpm. Sometimes it is necessary to redirect all clients, except admin (190.212.201.0/24), to "Service unavailable" page which is simple index.html file with logo, background image and some text, located in /unav directory.
Below  some of nginx.conf


location / {

if ($remote_addr !~ '190\.212\.201\.[0-9]{0,3}') {
rewrite ^/(.*)$ /unav/$1 break;
return 403;
}
try_files $uri $uri/ &amp;lt; at &amp;gt;opencart;
}

location ^~ /unav {
}

location &amp;lt; at &amp;gt;opencart {
rewrite ^/(.+)$ /index.php?_route_=$1 last;
}

[...skipped...]

location ~ \.php$ {

         try_files      $uri =404;
         fastcgi_read_timeout 60s;
         fastcgi_send_timeout 60s;
         include           myphp-fpm.conf;

                    }

Problem  is in rewriting.
This rule

rewrite ^/(.*)$ /unav/$1 break;

rewrite ONLY http://mysite.com/ request but in case http://mysite.com/index.php rewrite is none and request processed by location ~ \.php$ rule. Why??

Thanks!
&lt;/pre&gt;</description>
    <dc:creator>wishmaster</dc:creator>
    <dc:date>2013-05-23T20:11:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39037">
    <title>Re: NGINX error log format documentation</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39037</link>
    <description>&lt;pre&gt;
Hi there,

 
  less src/core/ngx_log.c

should probably show most of what you need. Combine that with

  grep -r -A 2 ngx_log_error src

and looking at an error log and you should see that it is "a small number
(five, I think) of fixed fields, followed by free-form text".


I (strongly) suspect that the error log line format details is not
something that nginx wants to commit to holding stable.

If you want to do any more parsing than "free-form text after a handful of
common fields", then you'll probably want to care about the version you
are using. Or at least, flag an imperfectly-recognised line if anything
doesn't match what you expect.


It's hard to beat the contents of src/ for accuracy.

Choose the "identifying" string in the line you care about, find the
matching ngx_error_log call, and then see what free-form text it provides
in the current version.

f
&lt;/pre&gt;</description>
    <dc:creator>Francis Daly</dc:creator>
    <dc:date>2013-05-23T19:31:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39036">
    <title>NGINX error log format documentation</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39036</link>
    <description>&lt;pre&gt;Hey!

I want to parse NGINX error logs. However, I did not find any 
documentation concerning the used log format. While the meaning of some 
fields like the data is pretty obvious, for some it is not at all. In 
addition, I cannot be sure that my parser is complete if I do not have a 
documentation of all the possible fields. Since it seems you can change 
the access log format, but not that of the error log, I really have no 
idea how to get the information I need.

Is there such documentation?

I also posted this question on StackOverflow: 
http://stackoverflow.com/questions/16711573/nginx-error-log-format-documentation/16711684

Thank you!


_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Jan Teske</dc:creator>
    <dc:date>2013-05-23T18:47:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39035">
    <title>Re: streaming request</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39035</link>
    <description>&lt;pre&gt;
People are asking for "no buffer" feature very often,
it's clearly something nginx is missing and should have. 

I know Weibin has been working on a patch to do exactly that ("no_buffer" patch).
Currently it's available and stable for nginx 1.2.x,
but the 1.4 version is still work-in-progress. 

&lt;/pre&gt;</description>
    <dc:creator>Pasi Kärkkäinen</dc:creator>
    <dc:date>2013-05-23T18:13:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39034">
    <title>Re: Updated cross-reference (LXR)</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39034</link>
    <description>&lt;pre&gt;If somebody wants cross reference for other versions, here you can find for
almost all versions on nginx http://osxr.org/ngx/source

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,220726,239479#msg-239479
&lt;/pre&gt;</description>
    <dc:creator>artemg</dc:creator>
    <dc:date>2013-05-23T15:43:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39033">
    <title>Re: Override Content-Type header with proxied requests</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39033</link>
    <description>&lt;pre&gt;Oops it's $upstream_http_content_type instead. Should read:

map $upstream_http_content_type $s3_content_type {
    # S3 -&amp;gt; real...
}


----appa



On Thu, May 23, 2013 at 5:24 PM, António P. P. Almeida &amp;lt;appa-rjfhcOcFV6XR7s880joybQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt;wrote:

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>António P. P. Almeida</dc:creator>
    <dc:date>2013-05-23T15:33:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39032">
    <title>Re: Override Content-Type header with proxied requests</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39032</link>
    <description>&lt;pre&gt;Try this.

At the http level define a map directive that maps upstream Content-Types
to the correct ones.

map $upstream_content_type $s3_content_type {
    # S3 -&amp;gt; real...
}

On the location that proxy passes.

proxy_hide_header Content-Type;
add_header Content-Type $s3_content_type;

----appa



On Thu, May 23, 2013 at 5:07 PM, andrea.mandolo &amp;lt;nginx-forum-LhBSS6c2AZM&amp;lt; at &amp;gt;public.gmane.org&amp;gt;wrote:

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>António P. P. Almeida</dc:creator>
    <dc:date>2013-05-23T15:24:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39031">
    <title>How to tell nginx to check dead backend in upstream adaptively?</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39031</link>
    <description>&lt;pre&gt;Hi,

Currently nginx will check every fail_timeout (default=10s) which is too
frequent when the backend server dead completely that require manually
replacement and it might take long time.

Definitely we can mark it as down in the config, but that is not an
automatic solution.

Is it possible to config nginx that it check adaptively?
e.g. start from 10s, then 20s, 40s, 60s etc?

Or are there any better approach?

Thanks.
_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Ryan Chan</dc:creator>
    <dc:date>2013-05-23T15:17:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39030">
    <title>Re: Override Content-Type header with proxied requests</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39030</link>
    <description>&lt;pre&gt;Here's a thread I started on this a while back. I didn't get any replies.

http://mailman.nginx.org/pipermail/nginx/2011-September/029344.html

Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html
&lt;/pre&gt;</description>
    <dc:creator>Jonathan Matthews</dc:creator>
    <dc:date>2013-05-23T15:11:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39029">
    <title>Override Content-Type header with proxied requests</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39029</link>
    <description>&lt;pre&gt;Hi !!

i have a Nginx server that operates as a reverse proxy to a my bucket in
Amazon S3.

Amazon S3 service could deliver contents with wrong Content-Type header,
so i would like to override this header by referring to file extension.

In other servers i have just configured the "types" block with all mime
types mapped with file estensions,
but this approach only works when Nginx delivers contents directly (as a
origin server).
If the server is a reverse proxy, doesn't add a new Content-Type header, but
honors Content-Type (if exists) received by the origin.

Is it possible to override the content-type response header using "types"
block? Is there any best practice to override content-type header by file
extensions? Is "map" suggested for this purpose or using multiple "location"
block is better?

Thanks in advance!!
---
Andrea

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,239473,239473#msg-239473
&lt;/pre&gt;</description>
    <dc:creator>andrea.mandolo</dc:creator>
    <dc:date>2013-05-23T15:07:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39028">
    <title>Re: Problem with rewrite regexes when the URL contains a trailing slash (nginx-1.5.0)</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39028</link>
    <description>&lt;pre&gt;Hello -- just writing again to say that I did it! I found on the web 
(just Google) a Cygwin build of nginx and it works perfectly.
Thanks for your support!
Robertof

Il 22/05/2013 21:12, Maxim Dounin ha scritto:

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Roberto F.</dc:creator>
    <dc:date>2013-05-22T21:15:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39027">
    <title>Re: Problem with rewrite regexes when the URL contains a trailing slash (nginx-1.5.0)</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39027</link>
    <description>&lt;pre&gt;Hi, thanks for the fast answer!
Yes, I am using nginx on Windows and I didn't know about that restriction.
Since the project I'm working on requires that (damned!) final point, do 
you know a way to overcome this restriction?
For example, I thought about cygwin but I'm not sure if it would work.

Thanks again,
Robertof

Il 22/05/2013 21:12, Maxim Dounin ha scritto:

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Roberto F.</dc:creator>
    <dc:date>2013-05-22T19:17:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39026">
    <title>Re: Problem with rewrite regexes when the URL contains a trailing slash (nginx-1.5.0)</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39026</link>
    <description>&lt;pre&gt;Hello!

On Wed, May 22, 2013 at 08:40:43PM +0200, Roberto F. wrote:


Are you using nginx/Windows?  On Windows trailing dots and spaces 
in URIs are ignored as they aren't significant from filesystem 
point of view and otherwise can be used to bypass access 
restrictions.

&lt;/pre&gt;</description>
    <dc:creator>Maxim Dounin</dc:creator>
    <dc:date>2013-05-22T19:12:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39025">
    <title>Problem with rewrite regexes when the URL contains a trailing slash (nginx-1.5.0)</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39025</link>
    <description>&lt;pre&gt;Hello.
I'm having a problem with nginx's rewrite directive.
Basically, when the URL contains a trailing point, it is ignored by the 
rewrite regexp.
Let's do an example:
I load http://uri/something. (with the trailing point). Then, with the 
rewrite rule:
rewrite ^/something\.$ /index.html
I should see 'index.html', but instead that appears in the logfile (with 
rewrite_log set at on):
2013/05/22 20:36:07 [notice] 6256#1440: *57 "^/something\.$" does not 
match "/something", client: 127.0.0.1, server: localhost, request: "GET 
/something. HTTP/1.1", host: "localhost"
As you can see, the trailing point is missing from the "does not match" 
part of the log.

Is there any workaround for that?
Thank you in advance,
Robertof

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Roberto F.</dc:creator>
    <dc:date>2013-05-22T18:40:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39024">
    <title>Re: Nginx returns HTTP 200 with Content-Length: 0</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39024</link>
    <description>&lt;pre&gt;Hello!

On Tue, May 21, 2013 at 09:56:59PM -0400, apeman wrote:


You may want to capture debug log to see what goes on, see 
http://nginx.org/en/docs/debugging_log.html for details.

See also http://wiki.nginx.org/Debugging#Asking_for_help.

&lt;/pre&gt;</description>
    <dc:creator>Maxim Dounin</dc:creator>
    <dc:date>2013-05-22T15:20:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39023">
    <title>Re: Using http_limit_conn with a custom variable</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39023</link>
    <description>&lt;pre&gt;Ah, thanks, map{} is probably the best solution. We got it "working" by
using rewrite_by_lua_file, which let us set new headers:

    # Set an HTTP header that is read by conn_zone
    rewrite_by_lua_file user.lua;

    limit_conn_zone $http_user_binary ...;

Then in the lua file, add something like:

    ngx.set_header('User-Binary', ngx.md5_bin($remote_user));

This is almost certainly not an ideal thing to do, we'll look to rewrite it
using map.

Thanks,
Kevin


----
Kevin Burke | 415-723-4116 | www.twilio.com


On Wed, May 22, 2013 at 6:59 AM, Maxim Dounin &amp;lt;mdounin-ux0u7sevaKovJsYlp49lxw&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

_______________________________________________
nginx mailing list
nginx-jCiJ2l+ov5bYtjvyW6yDsg&amp;lt; at &amp;gt;public.gmane.org
http://mailman.nginx.org/mailman/listinfo/nginx&lt;/pre&gt;</description>
    <dc:creator>Kevin Burke</dc:creator>
    <dc:date>2013-05-22T14:35:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39022">
    <title>Re: Using http_limit_conn with a custom variable</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39022</link>
    <description>&lt;pre&gt;Hello!

On Tue, May 21, 2013 at 12:31:05PM -0700, Kevin Burke wrote:


For variables processing independant on a particular request 
handling point there is the map{} and perl_set directives in 
nginx (see http://nginx.org/r/map, http://nginx.org/r/perl_set).  

Not sure if there is something similar in lua module, but map 
should be enough for a particula task.

With map you may do something like this:

    map $remote_user $limit {
        default      invalid;
        ~^[a-z0-9]+$ $remote_user;
    }

This way only valid (according to a regex) user names are mapped 
to their own limits, while everything else maps to predefined 
value "invalid".

&lt;/pre&gt;</description>
    <dc:creator>Maxim Dounin</dc:creator>
    <dc:date>2013-05-22T13:59:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39021">
    <title>Re: NGINX SE vs. Open Source</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39021</link>
    <description>&lt;pre&gt;Hi JackB,

On May 22, 2013, at 1:38 PM, JackB &amp;lt;nginx-forum-LhBSS6c2AZM&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:


There are certain enhancements over load balancing, monitoring and
configuration, as well as additional media streaming related capabilities in
the commercial subscription. This product is still pending public
announcement and the list of features is subject to change.

You right with the web site, though. The .com web site still requires a lot
of work and will be improved in the short term.


No, that's not an option, and there're no such plans.

Everything that's currently in the OSS version of nginx will remain as OSS,
licensed under the 2-clause BSD-like license.

Moreover, we keep fixing a lot of things in the OSS nginx (check the CHANGES),
as well as  adding new (and big) features like OCSP Stapling, WebSocket or
SPDY to the OSS nginx.

Like it was said before several times (and I'd like to reiterate it once again),
we at Nginx, Inc. are fully dedicated to introduce major improvements
to the OSS nginx, and&lt;/pre&gt;</description>
    <dc:creator>Andrew Alexeev</dc:creator>
    <dc:date>2013-05-22T12:05:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39020">
    <title>NGINX SE vs. Open Source</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39020</link>
    <description>&lt;pre&gt;Hello,

on your Site (http://nginx.com/products.html) you are comparing NGINX SE
with the Open Source version. The table states "Basic" and "Enhanced" on
many core features of NGINX. The SE/"Enhanced" column offers additional
information by hovering with the mouse over the rows. Those additional
information are listing well known features from the Open Source version.
Since there is no detailed comparison (and _NO HOVER_ on the "Basic"
column), can you clarify:

- what exactly the differences are on the listed features?
- will currently offered features of the Open Source version be moved to the
SE version? (means: removed from the Open Source version)
- will there be a documentation of how SE features work and what they
offer?

Thanks.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,239424,239424#msg-239424
&lt;/pre&gt;</description>
    <dc:creator>JackB</dc:creator>
    <dc:date>2013-05-22T09:38:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.nginx.english/39019">
    <title>Re: Nginx returns HTTP 200 with Content-Length: 0</title>
    <link>http://permalink.gmane.org/gmane.comp.web.nginx.english/39019</link>
    <description>&lt;pre&gt;no, no, no!
Normally, it's not 0, but sometimes, the possibility is 0.07%. It's
absolutely not normal!
[21/May/2013:00:02:56 +0800] "POST /ourservice/api HTTP/1.1" 200 607 27 "-"
"c" "10.23.130.154"  
[21/May/2013:00:02:56 +0800] "POST /ourservice/api HTTP/1.1" 200 613 27 "-"
"c" "10.59.24.83"    
[21/May/2013:00:02:56 +0800] "POST /ourservice/api HTTP/1.1" 200 604 62 "-"
"e" "10.197.218.20"  
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.1" 200 491 27 "-"
"f" "-"              
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.1" 200 612 278 "-"
"f" "10.165.21.34"  
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.0" 200 816 27 "-"
"c" "10.26.152.101"  
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.1" 200 585 27 "-"
"c" "10.67.55.190"   
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.1" 200 463 211 "-"
"f" "-"             
[21/May/2013:00:02:57 +0800] "POST /ourservice/api HTTP/1.1" 200 596 0 "-"
"f" "10.181.30.95"    
You see the last column, the response &lt;/pre&gt;</description>
    <dc:creator>apeman</dc:creator>
    <dc:date>2013-05-22T01:56:59</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.web.nginx.english">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.web.nginx.english</link>
  </textinput>
</rdf:RDF>
