cpp-netlib-devel

[cpp-netlib-devel] Assumption about response headers

[Ivan J. <ijo...@gm...>]

Hi Dean,

I've just downloaded library and built the http_client.cpp sample. Testing
it out by giving it the URL: http://www.google.com results in a "Missing
Transfer Encoding" exception. Looking the code in sync_connection_base.hpp I
see that either a Content-Length or Transfer-Encoding header is required.
However, the response fromwww.google.com does not contain a message body(I
assume because the Connection:close header was included in the request),
thus the presence of either of those headers are optional.  Thoughts?

Ivan Johannessen

Re: [cpp-netlib-devel] Assumption about response headers

[Dean M. B. <mik...@gm...>]

Hi Ivan,

On Sat, Jun 5, 2010 at 12:51 AM, Ivan Johannessen
<ijo...@gm...> wrote:
> Hi Dean,
> I've just downloaded library and built the http_client.cpp sample.

What version did you download?

> Testing
> it out by giving it the URL: http://www.google.com results in a "Missing
> Transfer Encoding" exception. Looking the code in sync_connection_base.hpp I
> see that either a Content-Length or Transfer-Encoding header is required.
> However, the response fromwww.google.com does not contain a message body(I
> assume because the Connection:close header was included in the request),
> thus the presence of either of those headers are optional.  Thoughts?

Actually I would say it's because the client in the HTTP example
doesn't follow directs automatically (IIRC). I need to check this.

The 0.6.1 version has an HTTP client that is HTTP/1.1 compliant and
thus should support already HTTP/1.0 responses from servers. In the
HTTP/1.1 spec, the server's HTTP/1.1 response *should* contain either
a Transfer-Encoding header, or a Content-Length header.

In the case of the example, I don't think it adds the
"follow_redirects" constructor option. I'll dig into it later but can
you check whether the response is an HTTP 200 or an HTTP 302?

Thanks and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Assumption about response headers

[Ivan J. <ijo...@gm...>]

On Fri, Jun 4, 2010 at 7:52 PM, Dean Michael Berris
<mik...@gm...>wrote:

> Hi Ivan,
>
> On Sat, Jun 5, 2010 at 12:51 AM, Ivan Johannessen
> <ijo...@gm...> wrote:
> > Hi Dean,
> > I've just downloaded library and built the http_client.cpp sample.
>
> What version did you download?
>
> I downloaded the 0.6.1 tag and pulled in the changes from the 0.7 branch
that allowed me to compile without SSL support.

> > Testing
> > it out by giving it the URL: http://www.google.com results in a "Missing
> > Transfer Encoding" exception. Looking the code in
> sync_connection_base.hpp I
> > see that either a Content-Length or Transfer-Encoding header is required.
> > However, the response fromwww.google.com does not contain a message
> body(I
> > assume because the Connection:close header was included in the request),
> > thus the presence of either of those headers are optional.  Thoughts?
>
> Actually I would say it's because the client in the HTTP example
> doesn't follow directs automatically (IIRC). I need to check this.
>
> The 0.6.1 version has an HTTP client that is HTTP/1.1 compliant and
> thus should support already HTTP/1.0 responses from servers. In the
> HTTP/1.1 spec, the server's HTTP/1.1 response *should* contain either
> a Transfer-Encoding header, or a Content-Length header.
>
> In the case of the example, I don't think it adds the
> "follow_redirects" constructor option. I'll dig into it later but can
> you check whether the response is an HTTP 200 or an HTTP 302?
>
> The http_client.cpp do follow redirects and the response is a HTTP/1.1
response with status 200. This issue is by no means a show stopper for me
but I pointed it out because I believe it is in disagreement of the RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616.html

I could not find anything in the RFC that stated that a response without a
body "should" or "must" contain either headers.


> Thanks and I hope this helps!
>
> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] Assumption about response headers

[Dean M. B. <mik...@gm...>]

On Sun, Jun 6, 2010 at 1:11 AM, Ivan Johannessen <ijo...@gm...> wrote:
>
>
> On Fri, Jun 4, 2010 at 7:52 PM, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> What version did you download?
>>
> I downloaded the 0.6.1 tag and pulled in the changes from the 0.7 branch
> that allowed me to compile without SSL support.

Cool.

>>
>> In the case of the example, I don't think it adds the
>> "follow_redirects" constructor option. I'll dig into it later but can
>> you check whether the response is an HTTP 200 or an HTTP 302?
>>
> The http_client.cpp do follow redirects and the response is a HTTP/1.1
> response with status 200. This issue is by no means a show stopper for me
> but I pointed it out because I believe it is in disagreement of the
> RFC: http://www.w3.org/Protocols/rfc2616/rfc2616.html
> I could not find anything in the RFC that stated that a response without a
> body "should" or "must" contain either headers.
>

That's odd, you don't get a body from the HTTP 200 OK response from
www.google.com?

Conforming HTTP 1.1 servers should use an HTTP 204 No Content response
instead if it doesn't intend to send a body. Although an HTTP 200 OK
should have either a "Content-Length" or "Transfer-Encoding: chunked"
last time I checked.

I'll try to look deeper into this though, thanks for reporting.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Assumption about response headers

[Ivan J. <ijo...@gm...>]

On Sun, Jun 6, 2010 at 7:01 AM, Dean Michael Berris
<mik...@gm...>wrote:

> On Sun, Jun 6, 2010 at 1:11 AM, Ivan Johannessen <ijo...@gm...>
> wrote:
> >
> >
> > On Fri, Jun 4, 2010 at 7:52 PM, Dean Michael Berris <
> mik...@gm...>
> > wrote:
> >>
> >> What version did you download?
> >>
> > I downloaded the 0.6.1 tag and pulled in the changes from the 0.7 branch
> > that allowed me to compile without SSL support.
>
> Cool.
>
> >>
> >> In the case of the example, I don't think it adds the
> >> "follow_redirects" constructor option. I'll dig into it later but can
> >> you check whether the response is an HTTP 200 or an HTTP 302?
> >>
> > The http_client.cpp do follow redirects and the response is a HTTP/1.1
> > response with status 200. This issue is by no means a show stopper for me
> > but I pointed it out because I believe it is in disagreement of the
> > RFC: http://www.w3.org/Protocols/rfc2616/rfc2616.html
> > I could not find anything in the RFC that stated that a response without
> a
> > body "should" or "must" contain either headers.
> >
>
> That's odd, you don't get a body from the HTTP 200 OK response from
> www.google.com?
>
> That is correct.


> Conforming HTTP 1.1 servers should use an HTTP 204 No Content response
> instead if it doesn't intend to send a body. Although an HTTP 200 OK
> should have either a "Content-Length" or "Transfer-Encoding: chunked"
> last time I checked.
>
> I'll try to look deeper into this though, thanks for reporting.
>
> Ah, looks like google is not doing the right thing. Thanks for a great lib.
I'll be using it in a cross platform(Windows/OSX/Linux) app soon.

Ivan

> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] Assumption about response headers

[Dean M. B. <mik...@gm...>]

On Tue, Jun 8, 2010 at 1:40 AM, Ivan Johannessen <ijo...@gm...> wrote:
>
>
> On Sun, Jun 6, 2010 at 7:01 AM, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> That's odd, you don't get a body from the HTTP 200 OK response from
>> www.google.com?
>>
> That is correct.
>

Whan you say you don't get a body, that means cpp-netlib already throws right?

I checked the RFC again and it seems I forgot to support the case
where the server just streams the contents and closes the connection
without specifying a transfer-encoding nor a content-length (as
described by http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4)
which is an oversight on my part.

Please file an issue at
http://github.com/mikhailberis/cpp-netlib/issues so I can track the
fix for it. I don't think it would be hard to fix it but I would like
to track work done against it so I can "focus". :)

>>
>> Conforming HTTP 1.1 servers should use an HTTP 204 No Content response
>> instead if it doesn't intend to send a body. Although an HTTP 200 OK
>> should have either a "Content-Length" or "Transfer-Encoding: chunked"
>> last time I checked.
>>
>> I'll try to look deeper into this though, thanks for reporting.
>>
> Ah, looks like google is not doing the right thing. Thanks for a great lib.
> I'll be using it in a cross platform(Windows/OSX/Linux) app soon.

Cool, you might want to hold off until I fix the bug with the HTTP 1.1
client implementation. :)

Have a great week ahead and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Assumption about response headers

[Ivan J. <ijo...@gm...>]

On Mon, Jun 7, 2010 at 10:39 PM, Dean Michael Berris <mik...@gm...
> wrote:

> On Tue, Jun 8, 2010 at 1:40 AM, Ivan Johannessen <ijo...@gm...>
> wrote:
> >
> >
> > On Sun, Jun 6, 2010 at 7:01 AM, Dean Michael Berris <
> mik...@gm...>
> > wrote:
> >>
> >> That's odd, you don't get a body from the HTTP 200 OK response from
> >> www.google.com?
> >>
> > That is correct.
> >
>
> Whan you say you don't get a body, that means cpp-netlib already throws
> right?
>
> Yes. Sorry for not being clear on this.


> I checked the RFC again and it seems I forgot to support the case
> where the server just streams the contents and closes the connection
> without specifying a transfer-encoding nor a content-length (as
> described by http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4)
> which is an oversight on my part.
>
> Please file an issue at
> http://github.com/mikhailberis/cpp-netlib/issues so I can track the
> fix for it. I don't think it would be hard to fix it but I would like
> to track work done against it so I can "focus". :)
>
> Will do.


> >>
> >> Conforming HTTP 1.1 servers should use an HTTP 204 No Content response
> >> instead if it doesn't intend to send a body. Although an HTTP 200 OK
> >> should have either a "Content-Length" or "Transfer-Encoding: chunked"
> >> last time I checked.
> >>
> >> I'll try to look deeper into this though, thanks for reporting.
> >>
> > Ah, looks like google is not doing the right thing. Thanks for a great
> lib.
> > I'll be using it in a cross platform(Windows/OSX/Linux) app soon.
>
> Cool, you might want to hold off until I fix the bug with the HTTP 1.1
> client implementation. :)
>
> Have a great week ahead and I hope this helps!
>
> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>