Hello,
   We have been developing a Server with considering only
   MUST requirments. but we r facing a problem to input and get
   output from a CGI script without using any third library function.
   Can anybody help us to overcome this problem
Best Regards,
Ripudaman Singh

On Thu, 6 May 2004, ripuda wrote:

>   we have been developing a HTTP/1.1 server that will support
>   cgi scripts. please any body let me know how should i get the
>   output of a cgi or perl script. though, we know that these script
>   program sends their output on STDOUT device but how the server
>   should read or get that output

The exact solution would depend on your programming language,
libraries you can use, operating system, desired performance, and a
set of features you want to support. All of the above may affect how
one captures the output of a program from another program. For a
simple, partial, C-centric solution, consider using a popen(3) call.

There are open source servers with elaborate CGI support; in theory,
you may be able to extract the logic and specifics from Apache httpd
or another open source server.

Note that, ideally, you also want to capture and log STDERR output of
a CGI script.

None of the above is related to HTTP or HTTP compliance so you may
want to find a more appropriate venue for followup questions.

Alex.

--
Protocol performance, functionality, and reliability testing.
Tools, services, and know-how.
http://www.measurement-factory.com/

Hi all,
   we have been developing a HTTP/1.1 server that will support
   cgi scripts. please any body let me know how should i get the
   output of a cgi or perl script. though, we know that these script
   program sends their output on STDOUT device but how the server
should read or get that output
Thank in advance
ripudaman singh
software engineer

Hello,

I've noticed the following behaviour between ie version 5, 5.5 and
6...

If the browser makes a GET request that returns a HTML page that
references static cachable resources and these have been cached on the
browser then no request is made to the server.

In IE 5.0 and some (not all) IE 5.5 versions if the browser makes a
POST request  who's response is HTML that references the same static
resource then the browser makes a conditional GET to which the server
responds 304.  This doesn't happen in IE 6.  This also happens if the
browser makes a POST who's response is a redirect to a GET for a page
with the static resource -- same 304 behaviour.

This causes a problem to the subset of our users who have high network
latency so that a 304 is nearly as bad as a full GET.

Has anyone seen this before?

Anyone know if Microsoft have recorded this behaviour?

Cheers,

Dave.

On Thu, 29 Jan 2004, colin_cj_macdonald wrote:

> I'm currently pruning 2616 down to a list of the actual
> requirements, but it occurs to me that someone must (MUST) have done
> this already.  Can anyone point me to an existing list of compliant
> requirements?

A list of MUST-level requirements (cross-linked with the RFC 2026 text
and test cases, where applicable) is a part of the Co-Advisor test
suite:

http://coad.measurement-factory.com/cgi-bin/coad/GraseIndexCgi?index_ids=CLAUSES
http://coad.measurement-factory.com/cgi-bin/coad/GraseIndexCgi?index_ids=GROUPS

It would be fairly straightforward to add MAYs and SHOULDs to the
above, but few people care about those.

> Also, can I be the 837rd person to ask if anyone knows of any tools
> to test *client* compliance.  A commercial solution would be fine.

Folks indeed want client-side tests, but, so far, we have been unable
to find a company willing to pay for them; a few came very close
though, so there is still hope. Since you accept a commercial
solution, perhaps your company can be the first to sponsor one?

There are three basic approaches to client-side tests: the test suite
drives the client using some client-specific API, a human drives the
client using dynamic instructions from the test suite, and a test
suite does trace analyses of a real protocol chat. Which approach
would work better in your environment?

Alex.

--
Protocol performance, functionality, and reliability testing.
Tools, services, and know-how.
http://www.measurement-factory.com/

Hey ho all,

I'm currently pruning 2616 down to a list of the actual requirements,
but it occurs to me that someone must (MUST) have done this already.
Can anyone point me to an existing list of compliant requirements?

Also, can I be the 837rd person to ask if anyone knows of any tools to
test *client* compliance (I know about measurement-factory and
hcltechnologies for proxies and caches).  I've had a look at Jigsaw (
http://jigsaw.w3.org/HTTP/ ) which covers a few cases, but I'm looking
for a full RFC 2616 test that both validates client requests, and
provides clear references for what the client should display for each
response (with Jigsaw it's not clear what you're supposed to be
seeing).  A commercial solution would be fine.

Many thanks,

-Colin MacDonald-

--- Chris Pressey <chris_pressey@...> wrote: > Hello again,
> I think I have come up with an absolutely minimal logic for an
> origin server reacting to If-* headers that remains conditionally
> compliant with RFC 2616, but I would appreciate a sanity check.
>
> The pseudocode is:

Oops, let me make a tiny revision:

> if If-Match is present and it is not "*"
>   respond with 412 Precondition Failed
> if If-None-Match is "*"
>   begin
>     if the request method is neither "GET" nor "HEAD"
>       respond with 412 Precondition Failed
>     if neither If-Modified-Since nor If-Unmodified-Since is present
>       respond with 501 Not Implemented
>   end

if If-Unmodified-Since is present
   respond with 412 Precondition Failed

> otherwise respond with the requested resource

...in other words, pessimistically assume the resource has changed.

-Chris


______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca

Hello again,

--- Alex Rousskov <rousskov@...> wrote:
> The logic behind all If-* headers is not that complex after you
> digest RFC wording into something more systematic/algorithmic
> (which may take days).

Well, it took me a little longer than days :)
(Actually, I just hadn't had time to work on it over the summer.)

I think I have come up with an absolutely minimal logic for an
origin server reacting to If-* headers that remains conditionally
compliant with RFC 2616, but I would appreciate a sanity check.

The pseudocode is:


if If-Match is present and it is not "*"
   respond with 412 Precondition Failed
if If-None-Match is "*"
   begin
     if the request method is neither "GET" nor "HEAD"
       respond with 412 Precondition Failed
     if neither If-Modified-Since nor If-Unmodified-Since is present
       respond with 501 Not Implemented
   end
otherwise respond with the requested resource


I fully admit that the primary goal is for the code to be
minimal; specifically, I don't want to have code to parse
the date, and I want the set of possible responses to be as
small as possible.  I realize the 501 Not Implemented is a
bit "rude", but it doesn't appear to be in violation of
RFC 2616; the important part seems to be that I MUST NOT
serve the requested resource if If-None-Match matches
(i.e. in my ETag-less case, if it'd "*") in the absence of
If-[Un]modified-Since headers.

Unless I have missed something?

Thanks in advance for any help.

-Chris

______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca

-- FYI. No apologies to cross-subscribers for cross-posting. Alex.


---------- Forwarded message ----------
Date: Tue, 16 Sep 2003 12:33:52 -0600 (MDT)
From: Alex Rousskov <rousskov@...>
To: ietf-http-wg@...
Subject: compliant proxies found, at last


I would like to share a piece of good news with folks who care about
HTTP: Two HTTP proxies, an open-source RabbIT[1] and a commercial
implementation from Datapower[2], have recently managed to pass all
applicable RFC 2616 MUSTs that we could test. These are the first
compliant HTTP intermediaries we know of.

IIRC, it took both teams almost a year to fix all violations. If you
look at RabbIT and Datapower product descriptions, you will see that
these are real, full-featured content-aware proxies, not just some L4
tunnels that do not care about HTTP. From what I heard, a couple of
core design alternations were required to pass some of the tough test
cases. Now we have a living proof that it is possible to be
feature-reach and HTTP/1.1 compliant!

     Disclaimer: I do realize that passing all Co-Advisor test cases
     does not imply or guarantee formal compliance, even on conditional
     level.  I am sure that there are still bugs to be fixed. No
     testing can guarantee a bug-free implementation. We can never
     prove compliance by testing. When I say "compliant", I mean
     "passes all applicable MUST-level test cases". Call it a marketing
     trick/spin if you wish.

I applaud Patrick McManus (Datapower), Robert Olofsson (RabbIT), and
their development/QA teams on having the dedication and skills
required to support all relevant HTTP/1.1 MUSTs. I believe that their
success is significant, regardless of the marketing spin.

I hope you do not perceive this message as an ad for our test suite. I
tried hard to simply share the good news and praise the good guys :-).

Thank you,

Alex.

[1] http://www.khelekore.org/rabbit/
[2] http://www.datapower.com/

--- In http-compliance@yahoogroups.com, Alex Rousskov <rousskov@m...>
wrote:
>
> On Wed, 4 Jun 2003, chris_pressey wrote:
>
> > On the assumption that it is optional for an origin server to
> > generate ETags, would it also be acceptable to assume that:
> >
> > - any request with only If-Match will always return 412
>
> Except for
>  If-Match: *
> [...]
> > On the other hand, if ETags are a MUST, I suppose I will have to
> > consider the simplest way to generate them, first.
>
> Generating ETags is optional.

Thanks for all the pointers.  I'll make sure to include your name in
the credits under "compliancy help". :)

-Chris

On Wed, 4 Jun 2003, chris_pressey wrote:

> On the assumption that it is optional for an origin server to
> generate ETags, would it also be acceptable to assume that:
>
> - any request with only If-Match will always return 412

Except for
	 If-Match: *

> - any request with only If-None-Match will never return 412

Except for
	 If-None-Match: *
especially for non-GET/HEAD methods.

> ...since a client which sends my server any entity tags is obviously
> confused (since it couldn't have got them from my server! :)

In general, your server may be serving content that was previously
served by an ETag-generating server, explaining now-stale e-tags in
request headers; so the client is not necessarily "confused". The "*"
case is used to make PUTs and such safer.

Also be careful with If-Range if you are going to support ranges,
because If-Range can use HTTP-date as a validator (section 14.27) so
you cannot ignore it even if you generate no entity-tags.

> If this is the case it would greatly simplify my server; I would
> still have to add code to parse dates to satisfy If-Unmodified-Since
> (and at that point I might as well implement If-Modified-Since too,
> since it's a near-trivial variation on If-Unmodified-Since), but the
> logic for handling If-[None-]Match would remain minimal.

The logic behind all If-* headers is not that complex after you digest
RFC wording into something more systematic/algorithmic (which may take
days). The core of it can be expressed in less than 100 lines of code.
Nevertheless, if you can bypass all e-tag operations, your code will
be simpler, of course.

> On the other hand, if ETags are a MUST, I suppose I will have to
> consider the simplest way to generate them, first.

Generating ETags is optional.

Alex.

--
                             | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                             | all of the above - PolyBox appliance

--- In http-compliance@yahoogroups.com, Alex Rousskov <rousskov@m...>
wrote:
> There is no clear/single MUST that says "the server MUST support a
> conditional or partial GET", I think. However, you may still get a
> practical answer to your questions. I would just recommend looking
at
> the problem from a different point of view:
>
>  * Returning 412s for mismatched If-Match is a MUST (14.24).
> 	  Thus, you cannot ignore If-Match.
>
>  * Returning 304s for matching If-Modified-Since is a
> 	  SHOULD (Section 14.25). Thus, you can ignore
> 	  If-Modified-Since in this context.
>
>  * Returning 200s/304s for matching If-None-Match is
> 	  a MUST (14.26). Thus, you cannot ignore If-None-Match.
>
>  * If-Range MUST be ignored if the server does not
> 	  support the sub-range operation (14.27). Thus, you
> 	  can ignore If-Range. (Same for Range, BTW).
>
>  * Returning 412s for mismatching If-Unmodified-Since
> 	  is a MUST (14.28). Thus, you cannot ignore
> 	  If-Unmodified-Since.
>
>  * Returning 304s for mismatching If-Modified-Since
> 	  while other If-* headers match is a MUST NOT (13.3.4).
> 	  Thus, you cannot ignore If-Modified-Since if other
> 	  conditional headers are present. This rule probably
> 	  excludes If-Range since there is a more specific
> 	  MUST that says you can ignore it.
>
> At this point, we can conclude that you can ignore If-Range, but
must
> support/recognize/honor all other If-* headers if you want to be
> conditionally compliant in all cases. However, you can return 200 OK
> responses to matching If-Modified-Since requests as long as those
> requests do not contain other If-* headers.
>
> HTH,
>
> Alex.

Thanks for your reply.

Two of my primary design goals are conditional compliance and
simplicity, so I'd like to be able to reduce this problem to an
absolute, yet practical, minimum.  This brings me to a followup
question.

I have not yet seen a clear MUST in regard to generating and sending
ETags.  The closest I have seen are:

- "An entity tag MUST be unique across all versions of all entities
associated with a particular resource." (3.11)
- "Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second"
(13.2)

On the assumption that it is optional for an origin server to
generate ETags, would it also be acceptable to assume that:
- any request with only If-Match will always return 412
- any request with only If-None-Match will never return 412
...since a client which sends my server any entity tags is obviously
confused (since it couldn't have got them from my server! :)

If this is the case it would greatly simplify my server; I would
still have to add code to parse dates to satisfy If-Unmodified-Since
(and at that point I might as well implement If-Modified-Since too,
since it's a near-trivial variation on If-Unmodified-Since), but the
logic for handling If-[None-]Match would remain minimal.

On the other hand, if ETags are a MUST, I suppose I will have to
consider the simplest way to generate them, first.

Thanks again for your time.
-Chris

On Mon, 2 Jun 2003, chris_pressey wrote:

> I'm writing a minimal HTTP/1.1 origin server and I'm striving for
> conditional compliance.
>
> I have a couple of newbie questions about whether Conditional GET
> (and Partial GET) are required or merely recommended.

There is no clear/single MUST that says "the server MUST support a
conditional or partial GET", I think. However, you may still get a
practical answer to your questions. I would just recommend looking at
the problem from a different point of view:

	 * Returning 412s for mismatched If-Match is a MUST (14.24).
	   Thus, you cannot ignore If-Match.

	 * Returning 304s for matching If-Modified-Since is a
	   SHOULD (Section 14.25). Thus, you can ignore
	   If-Modified-Since in this context.

	 * Returning 200s/304s for matching If-None-Match is
	   a MUST (14.26). Thus, you cannot ignore If-None-Match.

	 * If-Range MUST be ignored if the server does not
	   support the sub-range operation (14.27). Thus, you
	   can ignore If-Range. (Same for Range, BTW).

	 * Returning 412s for mismatching If-Unmodified-Since
	   is a MUST (14.28). Thus, you cannot ignore
	   If-Unmodified-Since.

	 * Returning 304s for mismatching If-Modified-Since
	   while other If-* headers match is a MUST NOT (13.3.4).
	   Thus, you cannot ignore If-Modified-Since if other
	   conditional headers are present. This rule probably
	   excludes If-Range since there is a more specific
	   MUST that says you can ignore it.

At this point, we can conclude that you can ignore If-Range, but must
support/recognize/honor all other If-* headers if you want to be
conditionally compliant in all cases. However, you can return 200 OK
responses to matching If-Modified-Since requests as long as those
requests do not contain other If-* headers.

HTH,

Alex.

--
                             | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                             | all of the above - PolyBox appliance

Hi,

I'm writing a minimal HTTP/1.1 origin server and I'm striving for
conditional compliance.

I have a couple of newbie questions about whether Conditional GET
(and Partial GET) are required or merely recommended.

5.1.1 of RFC 2616 says:

"...if the above methods are implemented, they MUST be implemented
with the same semantics as those specified in section 9."

While 9.3 says:

"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)."

This implies to me that HTTP/1.1 origin servers MUST implement
Conditional GET.

However, 3.3.1 states:

"HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats..."

This implies to me that there can be HTTP/1.1 origin servers that do
not parse dates, and, since parsing dates is required for Conditional
GET, implies that they do not support Conditional GET.

Similarly for Partial GET, 9.3 says:

"The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field."

Whereas 14.35.2 says:

"A server MAY ignore the Range header."

At the moment I figure I've misinterpreted "the above methods" in
5.1.1 to mean all methods, when it really means all methods except
GET and HEAD - but I'd like confirmation on this.

Also - if Conditional GET and Partial GET are indeed optional, what
is the most graceful way to handle these requests: just ignore the
If-Match, Range, etc. headers and respond as if it were a plain GET?

Thanks in advance,
-Chris

HI gayathri,

can you send me details about the HTTP complaince test tool, I am
planning to test my proxy with it, I am specifically looking at
security issues related to HTTP

thanks

shiv
--- In http-compliance@yahoogroups.com, Gayathri Ramakrishnan
<gayramak@n...> wrote:
> Hi,
>
> We have a fully automated HTTP Complaince Test Tool, designed
> to carry out both 1.0 and 1.1 specific tests on a HTTP Proxy
> and thereby determine the level of compliance.
>
> If you need further details about the tool, please send us an
> email.
>
> Thanks,
> Gayathri
>
> We Pause, to soar higher
> Visit: http://cdn.hcltech.com
>
>
>
> François Gournay wrote:
> >
> > We have developed an HTTP Proxy and I need to test that it is
HTTP 1.0
> > and 1.1 compliant. Is there any automated tool to do this?
> > Thanx in advance.
> > --
> > Francois Gournay
> > Nextenso Customer Documentation
> > Tel : 33 1 55 59 38 08    Fax : 33 1 55 59 37 37
> >
> > To unsubscribe from this group, send an email to:
> > http-compliance-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

For the record: Co-Advisor, another fully automated HTTP complaince
test suite is available at http://coad.measurement-factory.com/
You can use the on-line interface or get software/appliance package
for in-house tests.

Alex.




On Tue, 6 Aug 2002, Gayathri Ramakrishnan wrote:

> Hi,
>
> We have a fully automated HTTP Complaince Test Tool, designed
> to carry out both 1.0 and 1.1 specific tests on a HTTP Proxy
> and thereby determine the level of compliance.
>
> If you need further details about the tool, please send us an
> email.
>
> Thanks,
> Gayathri
>
> We Pause, to soar higher
> Visit: http://cdn.hcltech.com
>
>
>
> François Gournay wrote:
>
> >
> > We have developed an HTTP Proxy and I need to test that it is HTTP 1.0
> > and 1.1 compliant. Is there any automated tool to do this?
> > Thanx in advance.
> > --
> > Francois Gournay
> > Nextenso Customer Documentation
> > Tel : 33 1 55 59 38 08    Fax : 33 1 55 59 37 37
> >
> > To unsubscribe from this group, send an email to:
> > http-compliance-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> http-compliance-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Hi,

We have a fully automated HTTP Complaince Test Tool, designed
to carry out both 1.0 and 1.1 specific tests on a HTTP Proxy
and thereby determine the level of compliance.

If you need further details about the tool, please send us an
email.

Thanks,
Gayathri

We Pause, to soar higher
Visit: http://cdn.hcltech.com



François Gournay wrote:
>
> We have developed an HTTP Proxy and I need to test that it is HTTP 1.0
> and 1.1 compliant. Is there any automated tool to do this?
> Thanx in advance.
> --
> Francois Gournay
> Nextenso Customer Documentation
> Tel : 33 1 55 59 38 08    Fax : 33 1 55 59 37 37
>
> To unsubscribe from this group, send an email to:
> http-compliance-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

François,

I'm not aware of any generic tool available for testing HTTP/1.x
compliance, but I would like to point out that there are some aspects of
HTTP/1.1 that are rarely exercised by web browsers.  Pipelining is
probably the number one feature mis-implemented by proxy servers and
origin servers claiming HTTP/1.1 compliance.  Support for TE is probably
another less-frequently exercised HTTP/1.1 feature.  The Mozilla browser
(http://www.mozilla.org) includes experimental pipelining support, but
you'll have to enable it manually (see "Edit : Preferences : Advanced :
HTTP Networking").

<rant>
I really wish the HTTP/1.1 spec included a way for servers to negotiate
support for pipelining.  In the current world there is unfortunately
little hope for a web browser to enable pipelining by default :-(
</rant>

Darin



François Gournay wrote:

>We have developed an HTTP Proxy and I need to test that it is HTTP 1.0
>and 1.1 compliant. Is there any automated tool to do this?
>Thanx in advance.
>--
>Francois Gournay
>Nextenso Customer Documentation
>Tel : 33 1 55 59 38 08    Fax : 33 1 55 59 37 37
>
>
>
>
>To unsubscribe from this group, send an email to:
>http-compliance-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>

We have developed an HTTP Proxy and I need to test that it is HTTP 1.0
and 1.1 compliant. Is there any automated tool to do this?
Thanx in advance.
--
Francois Gournay
Nextenso Customer Documentation
Tel : 33 1 55 59 38 08    Fax : 33 1 55 59 37 37

Hi,

	 I cannot decide if the following is a MUST-level requirement
(i.e., its violation prevents RFC 2616 compliance, even conditional):

    13.10 Invalidation After Updates or Deletions
    ...
    In order to prevent denial of service attacks, an invalidation based
    on the URI in a Location or Content-Location header MUST only be
    performed if the host part is the same as in the Request-URI.

Suppose the host part is not the same as in the Request-URI. Let's
also assume that the device did perform an invalidation, subjecting
itself to a potential DoS attack. Did the device violate a MUST-level
requirement? The answer seems to depend on how you bind "only":

	 [ ] Yes, this is a MUST violation because
		 foo MUST only blah if bar
	     implies
		 if not bar, foo MUST NOT blah

	 [ ] No, this is not a MUST violation because
		 foo MUST only blah if bar
	     implies just that
		 if bar, foo MUST blah
	     and requires nothing when bar is false

I suspect that the intended interpretation is "yes, this is a MUST
violation". Can anybody confirm? Is there really a problem with the
wording, or am I imagining an ambiguity?

Thank you,

Alex.

On Tue, 11 Jun 2002, Patrick McManus wrote:

> [Alex Rousskov: Tue, Jun 11, 2002 at 11:07:10AM -0600]
> > On Tue, 11 Jun 2002, Mark Nottingham wrote:
> >
> > > Thanks. So, from a client perspective, they might expect any of the
> > > following behaviours when sending a chunked POST;
> > > a) success
> > > b) 411 Length Required
> > > c) 5xx error
> > > d) connection close (proxy crashed or other fatal error)
> >
> >   e) a malformed/invalid message reaches the server (proxy
> >      corrupts message body and/or headers because it does
> >      not understand what is going on); the server reaction
> >      is difficult to predict, but it might include "200 OK"
> >      if the server/CGI was not able to detect that the message
> >      got corrupted and, for example, interpreted a portion of
> >      the POSTed data only (the worst case).
>
> f) 100 continue

g) nothing (i.e., the recipient [erroneously] waits for more data,
    without sending 100 continue)

Alex.

[Alex Rousskov: Tue, Jun 11, 2002 at 11:07:10AM -0600]
> On Tue, 11 Jun 2002, Mark Nottingham wrote:
>
> > Thanks. So, from a client perspective, they might expect any of the
> > following behaviours when sending a chunked POST;
> > a) success
> > b) 411 Length Required
> > c) 5xx error
> > d) connection close (proxy crashed or other fatal error)
>
>   e) a malformed/invalid message reaches the server (proxy
>      corrupts message body and/or headers because it does
>      not understand what is going on); the server reaction
>      is difficult to predict, but it might include "200 OK"
>      if the server/CGI was not able to detect that the message
>      got corrupted and, for example, interpreted a portion of
>      the POSTed data only (the worst case).

f) 100 continue

-Patrick

On Tue, 11 Jun 2002, Mark Nottingham wrote:

> Thanks. So, from a client perspective, they might expect any of the
> following behaviours when sending a chunked POST;
> a) success
> b) 411 Length Required
> c) 5xx error
> d) connection close (proxy crashed or other fatal error)

   e) a malformed/invalid message reaches the server (proxy
      corrupts message body and/or headers because it does
      not understand what is going on); the server reaction
      is difficult to predict, but it might include "200 OK"
      if the server/CGI was not able to detect that the message
      got corrupted and, for example, interpreted a portion of
      the POSTed data only (the worst case).

Alex.

> ----- Original Message -----
> From: "Carl Kugler" <kugler@...>
> To: <http-compliance@yahoogroups.com>
> Sent: Tuesday, June 11, 2002 8:28 AM
> Subject: Re: [http-compliance] Chunked POST
>
>
> > Mark-
> >
> > I can't speak for the official position.  The primary interoperability
> > problem is due to CGI 1.1 (and earlier).  CGI REQUIRES a CONTENT-LENGTH.
> > Some servlet engines also have this restriction.  Another possible
> problem
> > is due to proxies:  a proxy server is allowed to coalesce all the chunks
> > into a monolithic request.  In practice, you never see this, because it
> > could require ulimited buffer space on the proxy server, and because it
> > has bad effects on response time.
> >
> >     -Carl
> >
> >
> >
> >
> >
> >
> > "Mark Nottingham" <mnot@...>
> > 06/10/2002 10:14 PM
> > Please respond to http-compliance
> >
> >
> >         To:     <http-compliance@yahoogroups.com>
> >         cc:
> >         Subject:        [http-compliance] Chunked POST
> >
> >
> > Can someone remind me what the state of the art is re: chunked POST?
> From
> > what I can see, it's allowed, but there's not a good interoperability
> > story with 1.0, so it's mostly avoided.
> >
> > What's the official position, and what can a client reasonably expect if
> > they chunk a POST and there's a 1.1 server somewhere in the message
> path?
> >
> > Thanks,
> >
> >  --
> > Mark Nottingham
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > http-compliance-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> http-compliance-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Thanks. So, from a client perspective, they might expect any of the
following behaviours when sending a chunked POST;
a) success
b) 411 Length Required
c) 5xx error
d) connection close (proxy crashed or other fatal error)

Is this accurate?


Thanks again,


----- Original Message -----
From: "Carl Kugler" <kugler@...>
To: <http-compliance@yahoogroups.com>
Sent: Tuesday, June 11, 2002 8:28 AM
Subject: Re: [http-compliance] Chunked POST


> Mark-
>
> I can't speak for the official position.  The primary interoperability
> problem is due to CGI 1.1 (and earlier).  CGI REQUIRES a CONTENT-LENGTH.
> Some servlet engines also have this restriction.  Another possible
problem
> is due to proxies:  a proxy server is allowed to coalesce all the chunks
> into a monolithic request.  In practice, you never see this, because it
> could require ulimited buffer space on the proxy server, and because it
> has bad effects on response time.
>
>     -Carl
>
>
>
>
>
>
> "Mark Nottingham" <mnot@...>
> 06/10/2002 10:14 PM
> Please respond to http-compliance
>
>
>         To:     <http-compliance@yahoogroups.com>
>         cc:
>         Subject:        [http-compliance] Chunked POST
>
>
> Can someone remind me what the state of the art is re: chunked POST?
From
> what I can see, it's allowed, but there's not a good interoperability
> story with 1.0, so it's mostly avoided.
>
> What's the official position, and what can a client reasonably expect if
> they chunk a POST and there's a 1.1 server somewhere in the message
path?
>
> Thanks,
>
>  --
> Mark Nottingham
>
>
>
> To unsubscribe from this group, send an email to:
> http-compliance-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
>
>

Mark,

	 FYI: Since supporting chunked encoded _messages_ is a MUST,
our HTTP compliance test suite has test cases that use chunked
_requests_. So far, none of the HTTP/1.1 proxies we have tested passed
all test cases with chunked requests. Some crashed.

	 So, regardless of the official position, this feature is not
well supported (yet?). Based on anecdotal evidence related to our
tests, many implementors seem to be taken by surprise: "ah, looks like
this MUST be supported, but we did not know that!".

	 To answer one of your questions, a client can reasonably
expect that their chunked POST will fail if there is a proxy in the
way. Hopefully, the situation will improve once we get implementors
attention.

Alex.

P.S. You can also find a few real-world cases with chunked requests:
	 http://www.google.com/search?q=chunked+request
	 http://www.google.com/search?q=chunked+request+Microsoft

On Mon, 10 Jun 2002, Mark Nottingham wrote:

> Can someone remind me what the state of the art is re: chunked
> POST? From what I can see, it's allowed, but there's not a good
> interoperability story with 1.0, so it's mostly avoided.
>
> What's the official position, and what can a client reasonably
> expect if they chunk a POST and there's a 1.1 server somewhere in
> the message path?
>
> Thanks,
>
>  --
> Mark Nottingham
>
>
>
> To unsubscribe from this group, send an email to:
> http-compliance-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Can someone remind me what the state of the art is re: chunked POST? From
what I can see, it's allowed, but there's not a good interoperability
story with 1.0, so it's mostly avoided.

What's the official position, and what can a client reasonably expect if
they chunk a POST and there's a 1.1 server somewhere in the message path?

Thanks,

  --
Mark Nottingham

I've been looking for a place to find a credit card. Here it is. My
credit was really bad but, they where able to appove me! Check it out!

Click on link Below!

http://apply4creditcard.com

hello all,
  Any body having the Test suite for HTTP Server ..
if so plse post it here bcoz i want to test my http server performance

Thanks in Advance
Kamaraj