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

On Thu, 24 Jan 2002, Mark Nottingham wrote:

> While we're all here, have a look at [1]; if you're aware of any
> headers that aren't on there, and have a reference for
> documentation, please send them along.

I think you are missing Proxy-Authentication-Info from RFC 2617.

Alex,

> [1]
http://www.ietf.org/internet-drafts/draft-nottingham-http-header-reg-00.txt

On Thu, Jan 24, 2002 at 05:20:23PM -0700, Alex Rousskov wrote:
> support was added long after Squid was fully operational.

Is that like the Death Star being fully operational?

Sorry... lost it there for a minute.


While we're all here, have a look at [1]; if you're aware of any
headers that aren't on there, and have a reference for documentation,
please send them along.

Cheers,


[1] http://www.ietf.org/internet-drafts/draft-nottingham-http-header-reg-00.txt


--
Mark Nottingham
http://www.mnot.net/

On Thu, 24 Jan 2002, Aniruddha Shevade wrote:

>  I have written a HTTP sever in C++/ According to the RFC 2616
> Section 4.2 it seems that the HTTP headers can span over multiple
> lines if the line is preceeded by space .  Trying to figure out a
> algorithm which would cover all possible scenarios seems
> difficult.

Yes, working with human-oriented formats like HTTP using
machine-oriented languages like C/C++ is difficult.

>    1) Will the appliaction be considered not compliant to HTTP 1.1
> if it can handle headers spanned over multiple lines

Section 4.2 does not contain explicit parsing requirements. That is,
it does not say something like "implementations MUST parse all
headers". However, since there are MUST requirements that rely on HTTP
servers analyzing specific headers, the application (IMO) will be
considered not compliant if it cannot parse valid headers such as
headers that span multiple lines.

Moreover, since support for spanning headers was added to Squid
caching proxy, I am guessing that there are clients out there that do
use this feature. I doubt there are many such clients since the said
support was added long after Squid was fully operational.

Alex.

Hello
  I have written a HTTP sever in C++/ According to the RFC 2616
Section 4.2 it seems that the HTTP headers can span  over multiple lines
if the line is preceeded by space .  Trying to figure out a algorithm which
would
cover all possible scenarios seems difficult.
    1) Will the appliaction be considered not compliant to HTTP 1.1 if it can
handle
headers spanned over multiple lines
   2) Is there any web site/ source code which I can refer
to get a idea of the HTTP parsing code  for in C++

Any help is appreciated

Thanks
-Aniruddha

hello all,
Anybody from this group has gone for Conformacne on
HTTP, pls reply back to me, so that i can clear my
doubts.

Looking forward for ur help.

Jacky

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Hi Alex,
Thanx for ur prompt response,
I m using SyncML toolkit, this is standard toolkit known as rtk
(Reference tookit) released by SyncML.org. It has provided some APIs,
these APIs r using some function in which null is passing at the
place of auth parameter.

So i have problem to use authentication.
Do u know or anybody can suggest to do it.

Jacky



--- In http-compliance@y..., Alex Rousskov <rousskov@m...> wrote:
> On Fri, 28 Dec 2001, catch2jacky wrote:
>
> > I want to use authorization at HTTP interface. How can HTTP
client
> > authenticate to itself and to the HTTP server?
>
> There are several authentication schemes. See, for example, RFC
2617:
>  HTTP Authentication: Basic and Digest Access Authentication
>
> > I have seen in the toolkit that httpopen() function pass NULL as
a
> > parameter for autorizatioin for server and client both. If i want
to
> > implement, can i change the NULL value to DEST_SERVER or
DEST_PROXY?
> >
> > One more thing how can i make chunked transfer encoding ?
> > It need to set the mode either in POST or PUT with datalength
equal
> > to zero. but by default httpopen() function sets the mode
EXCHANGE at
> > client side and SERVER at server side.
>
> I do not know which toolkit you are talking about. You may have
better
> luck forwarding these toolkit-specific questions to the toolkit
> support folks.
>
> Alex.

On Fri, 28 Dec 2001, catch2jacky wrote:

> I want to use authorization at HTTP interface. How can HTTP client
> authenticate to itself and to the HTTP server?

There are several authentication schemes. See, for example, RFC 2617:
	 HTTP Authentication: Basic and Digest Access Authentication

> I have seen in the toolkit that httpopen() function pass NULL as a
> parameter for autorizatioin for server and client both. If i want to
> implement, can i change the NULL value to DEST_SERVER or DEST_PROXY?
>
> One more thing how can i make chunked transfer encoding ?
> It need to set the mode either in POST or PUT with datalength equal
> to zero. but by default httpopen() function sets the mode EXCHANGE at
> client side and SERVER at server side.

I do not know which toolkit you are talking about. You may have better
luck forwarding these toolkit-specific questions to the toolkit
support folks.

Alex.

Hello All,
I want to use authorization at HTTP interface. How can HTTP client
authenticate to itself and to the HTTP server?

I have seen in the toolkit that httpopen() function pass NULL as a
parameter for autorizatioin for server and client both. If i want to
implement, can i change the NULL value to DEST_SERVER or DEST_PROXY?

One more thing how can i make chunked transfer encoding ?
It need to set the mode either in POST or PUT with datalength equal
to zero. but by default httpopen() function sets the mode EXCHANGE at
client side and SERVER at server side.

Thanx in advance.
Looking forward for ur help.

Regards,
Jacky

On Wed, 19 Dec 2001, Aniruddha Shevade wrote:

>    I have written a HTTP server which allows a user to Upload a File. The
> File is Sent as MIME attachment.

I assume you are talking about support for PUT request method. HTTP
does not use 'upload', 'file' or 'MIME attachment' terms.

> The probelm I have is if there is any problem in Uploading the
> file , should I be closing the connection to the client ?

HTTP is relatively clear about this case. You need to return
an appropriate error response before (optionally) closing the
connection. Here is what RFC 2616 has to say:

    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.

> If I do not do this then How do we handle the case that part of
> the file may be uploaded ?

HTTP does not talk about partial uploads (and it would be difficult to
define partial in a general case). Thus, your server has to decide
whether partial upload is success or failure, and act accordingly (see
above). The definition of 'success' is implementation-specific, of
course.

If you are talking about uploading a file using POST method (RFC 1867
"Form-based File Upload in HTML"), then HTTP does not talk about
special error handling for POST requests. However, an approach similar
to PUT can be used, I guess. A 'success' definition of POST is even
more implementation-specific.

Note that many (most?) HTTP servers do not support file upload
directly, but provide an interface for a 3rd party 'plugin' to handle
those requests. This is a natural choice given the fact that HTTP does
not define what it means to 'upload a file'.

Alex.

Hello
    I have written a HTTP server which allows a user to Upload a File. The
File is Sent as MIME attachment.
The probelm I have is if there is any problem in Uploading the file ,
should I be closing the connection
to the client ? If I do not do this then  How do we handle the case that
part of the file may be uploaded ?

Any help/ references are greatly appreciated

Thanks
-Aniurddha

This might be helpful:
   http://www1.ics.uci.edu/pub/ietf/http/rfc2145.txt



On Wed, Nov 28, 2001 at 10:08:58AM -0000, John Rodgers wrote:
> Hi,
>
> I'm writing an HTTP proxy (for fun) and was wondering about a
> response I got from an Apache web server ver 1.3.12.  I presented a
> GET with HTTP/1.0 as the version.  The response was HTTP/1.1 200 OK
> (etc).  I thought the server was supposed to degrade back to HTTP
> 1.0.  I noticed a similar response with IIS.  The server also
> returned a Connection header with a close value.  I didn't ask for a
> persistent connection so this didn't matter, but aren't web servers
> supposed to degrade the protocol back to match the requester?
>
> Thanks,
>   John
>
>
>
>
> 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 Nottingham
http://www.mnot.net/

[John Rodgers: Wed, Nov 28, 2001 at 10:00:18AM -0000]
> Hi,
>
> I'm writing an HTTP 1.0 proxy (for fun).  Things are going well
> except that when I refresh a page, IE 5 SP2 performs a GET with a If-
> None-Match header that has a quoted string and then an embedded null
> (just before CRLF).  From my understanding of the spec, the field
> content for an HTTP header is allowed to be text (no null allowed),
> token (no null), tspecial (no null), or quoted string (no null).  It
> appears to me that this null is invalid within a header (my current
> simple solution is to convert it to 01 so that I may treat the header
> as a single string).  The IIS/4.0 server provided this value in an
> ETAG field (no null).


The null is not allowed under the normal qdtext definition, because
TEXT prohibits octects 0-31 and 127.

        quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
        qdtext         = <any TEXT except <">>

        TEXT           = <any OCTET except CTLs,
                         but including LWS>
        CTL            = <any US-ASCII control character
                         (octets 0 - 31) and DEL (127)>

However, under the quoted-pair definition the NULL would be legal if
it were preceeded by a \

        quoted-pair    = "\" CHAR
        CHAR           = <any US-ASCII character (octets 0 - 127)>


>Is my understanding correct or must I allow
> for receiving nulls with an HTTP request header?

you're really asking two different questions.. if you're building a
proxy to enforce and check for http compliance (of major interest to
the http-compliance list!) then it would make sense to flag this.. but
if you're looking for interoperability, this is a very minor
infringement on the spec compared to some things you'll have to deal
with.

(wait til you see how many different ways people separate message
headers from message bodies.. (a personal favorite: many of these do
use 2xCRLF in their response but not for this purpose!) or how many
non-corrupted responses have content-length headers that don't match
the size of the response body, etc..)

-Pat

It is allowed to write a 1.1 response as long as it doesn't use any
features that cause interoperability with your 1.0 client - for instance
Transfer-Encoding: chunked

However, it could include something like ETag.. this would be helpful
to a 1.1 client on the other end of your proxy.

-P

[John Rodgers: Wed, Nov 28, 2001 at 10:08:58AM -0000]
> Hi,
>
> I'm writing an HTTP proxy (for fun) and was wondering about a
> response I got from an Apache web server ver 1.3.12.  I presented a
> GET with HTTP/1.0 as the version.  The response was HTTP/1.1 200 OK
> (etc).  I thought the server was supposed to degrade back to HTTP
> 1.0.  I noticed a similar response with IIS.  The server also
> returned a Connection header with a close value.  I didn't ask for a
> persistent connection so this didn't matter, but aren't web servers
> supposed to degrade the protocol back to match the requester?
>
> Thanks,
>   John
>
>
>
>
> 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/
>
>

From RFC 2616,

   The HTTP version of an application is the highest HTTP version for
   which the application is at least conditionally compliant.
 

   Proxy and gateway applications need to be careful when forwarding
   messages in protocol versions different from that of the application.
   Since the protocol version indicates the protocol capability of the
   sender, a proxy/gateway MUST NOT send a message with a version
   indicator which is greater than its actual version. If a higher
   version request is received, the proxy/gateway MUST either downgrade
   the request version, or respond with an error, or switch to tunnel
   behavior

   The proxy/gateway's response to that request MUST be in
   the same major version as the request

Thanks,
Sukanya.

John Rodgers wrote:

Hi,

I'm writing an HTTP proxy (for fun) and was wondering about a
response I got from an Apache web server ver 1.3.12.  I presented a
GET with HTTP/1.0 as the version.  The response was HTTP/1.1 200 OK
(etc).  I thought the server was supposed to degrade back to HTTP
1.0.  I noticed a similar response with IIS.  The server also
returned a Connection header with a close value.  I didn't ask for a
persistent connection so this didn't matter, but aren't web servers
supposed to degrade the protocol back to match the requester?

Thanks,
  John

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/3FDzZA/MkNDAA/ySSFAA/CefplB/TM
---------------------------------------------------------------------~->

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,

I'm writing an HTTP proxy (for fun) and was wondering about a
response I got from an Apache web server ver 1.3.12.  I presented a
GET with HTTP/1.0 as the version.  The response was HTTP/1.1 200 OK
(etc).  I thought the server was supposed to degrade back to HTTP
1.0.  I noticed a similar response with IIS.  The server also
returned a Connection header with a close value.  I didn't ask for a
persistent connection so this didn't matter, but aren't web servers
supposed to degrade the protocol back to match the requester?

Thanks,
   John

Hi,

I'm writing an HTTP 1.0 proxy (for fun).  Things are going well
except that when I refresh a page, IE 5 SP2 performs a GET with a If-
None-Match header that has a quoted string and then an embedded null
(just before CRLF).  From my understanding of the spec, the field
content for an HTTP header is allowed to be text (no null allowed),
token (no null), tspecial (no null), or quoted string (no null).  It
appears to me that this null is invalid within a header (my current
simple solution is to convert it to 01 so that I may treat the header
as a single string).  The IIS/4.0 server provided this value in an
ETAG field (no null).  Is my understanding correct or must I allow
for receiving nulls with an HTTP request header?

Thanks,
   John

Hello All,

I m writing an application over http protocol. I have written client
and server application but having one problem in two way
communication.

When server or client sends some data, it took data from the
beginning of the buffer every time but xml document is kept end of
the buffer. When i use a loop to send data, it sends all previous as
well as new data.

What i want to do, either
1. reset the buffer and then xml doc should write begining of the
buffer or
2. xml doc should write end of the buffer and begining pointer is
update to new pointer where the last data has been written.

I found that receiving and sending buffer are in the same address. so
when i tried to send the data, it also sends the received data even i
generated xml doc after receiving the data because it reads from the
begining of the buffer.

I know that i m missing something.
I wud appriciate if anybody give time to solve my problem.

Regards,
Jacky

Thanks.  That helps.

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@...]
> Sent: Tuesday, November 20, 2001 10:13 AM
> To: 'http-compliance@yahoogroups.com'
> Subject: Re: [http-compliance] Clarification of spec paragraph about
> headers with same name?
>
>
> On Tue, 20 Nov 2001, Karr, David wrote:
>
> > I'm confused because of the first sentence.  It says that
> > (paraphrased) "multiple header fields with the same name may be
> > present if the field-value for THAT header field is defined as a
> > comma-separated list".  I'm not certain of exactly what is being
> > said here.
>
> It means that if a header (denoted by its filed-name) is defined to
> have a comma-separated list field-value, then that header may be
> repeated. For example, the Date: header cannot be repeated while
> Connection: header can be repeated.
>
> Every header defined in HTTP has a field-name and a field-value. The
> format for the latter is header-specific.
>
> The idea is that if a header is repeated, the entire group of equally
> named headers can be treated/interpreted as a single header with a
> longer list of values in its field-value part. The only headers where
> concatenating field-values via a comma-separated list make sense are
> the headers that have comma-separated list field-value...
>
> Alex.
>
>
> > ------------------------
> > Multiple message-header fields with the same field-name MAY
> be present in a
> > message if and only if the entire field-value for that
> header field is
> > defined as a comma-separated list [i.e., #(values)]. It
> MUST be possible to
> > combine the multiple header fields into one "field-name:
> field-value" pair,
> > without changing the semantics of the
> > message, by appending each subsequent field-value to the first, each
> > separated by a comma. The order in which header fields with the same
> > field-name are received is therefore significant to the
> interpretation of
> > the combined field value, and thus a proxy MUST NOT change
> the order of
> > these field values when a message is forwarded.
> > ------------------------
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> StartMeUp jump starts your car's battery
> using only the cigarette lighter.
> $24.95 at Youcansave.com
> http://us.click.yahoo.com/mNb7gB/LTTDAA/ySSFAA/CefplB/TM
> --------------------------------------------------------------
> -------~->
>
> 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/

On Tue, 20 Nov 2001, Karr, David wrote:

> I'm confused because of the first sentence.  It says that
> (paraphrased) "multiple header fields with the same name may be
> present if the field-value for THAT header field is defined as a
> comma-separated list".  I'm not certain of exactly what is being
> said here.

It means that if a header (denoted by its filed-name) is defined to
have a comma-separated list field-value, then that header may be
repeated. For example, the Date: header cannot be repeated while
Connection: header can be repeated.

Every header defined in HTTP has a field-name and a field-value. The
format for the latter is header-specific.

The idea is that if a header is repeated, the entire group of equally
named headers can be treated/interpreted as a single header with a
longer list of values in its field-value part. The only headers where
concatenating field-values via a comma-separated list make sense are
the headers that have comma-separated list field-value...

Alex.


> ------------------------
> Multiple message-header fields with the same field-name MAY be present in a
> message if and only if the entire field-value for that header field is
> defined as a comma-separated list [i.e., #(values)]. It MUST be possible to
> combine the multiple header fields into one "field-name: field-value" pair,
> without changing the semantics of the
> message, by appending each subsequent field-value to the first, each
> separated by a comma. The order in which header fields with the same
> field-name are received is therefore significant to the interpretation of
> the combined field value, and thus a proxy MUST NOT change the order of
> these field values when a message is forwarded.
> ------------------------

The following paragraph in the HTTP 1.1 spec, the last paragraph in section
4.2, "Message Headers", talks about the possibility of having multiple
headers with the same name.  I would appreciate some clarification of this.

I'm confused because of the first sentence.  It says that (paraphrased)
"multiple header fields with the same name may be present if the field-value
for THAT header field is defined as a comma-separated list".  I'm not
certain of exactly what is being said here.

------------------------
Multiple message-header fields with the same field-name MAY be present in a
message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It MUST be possible to
combine the multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the interpretation of
the combined field value, and thus a proxy MUST NOT change the order of
these field values when a message is forwarded.
------------------------

Hello
   Is there any testing tool for checking the compliance of a HTTP server ?
Any htlp is appreciated

thanks
-aniruddha

Hi
   Just following a discussion, is there any place where I can get sample C++
code for
parsing HTTP headers. Looks like handling all the possible cases is pretty
complex
thanks
Aniruddha

-----Original Message-----
From: Alex Rousskov [mailto:rousskov@...]
Sent: Wednesday, October 31, 2001 2:24 PM
To: http-compliance@yahoogroups.com
Subject: Re: [http-compliance] newbie question: terminating characters
for a line


On Wed, 31 Oct 2001 darin@... wrote:

> in my experiences, web servers often mix \r\n and \n line endings in the
> header section.  as a result, it is common to ignore \r and only look
> for \n.

Yes, and doing so is explicitly recommended by HTTP:

    The line terminator for message-header fields is the sequence CRLF.
    However, we recommend that applications, when parsing such headers,
    recognize a single LF as a line terminator and ignore the leading CR.

though use of bare CR or LF is explicitly prohibited by HTTP:

    a bare CR or LF MUST NOT be substituted for CRLF within any of the
    HTTP control structures (such as header fields and multipart
    boundaries).

The usual IETF's garbage-in-treasure-out stuff...

I do not think this is related to the "can I have /n in any of the
header?" question. I think Aniruddha is trying to put \n inside the
*value* of an HTTP header field. I may be misinterpreting the original
question though...

Alex.

> Alex Rousskov wrote:
>
> >On Wed, 31 Oct 2001, Aniruddha Shevade wrote:
> >
> >> I am new to HTTP, and so please excuse me if this is a very basic
> >>question. Teh Http specification says that each HTTP header should
> >>be terminated by a CRLF i.e /r/n . Does this mean that I cannot
> >>have /n in any of the header .  Is There a way I can say that the
> >>\n in the header is not the terminator and just a part of the
> >>header data. This is required for me to test my HTTP parsing
> >>program
> >>
> >>Any help is appreciated
> >>
> >
> >The answer seems to be in HTTP specs:
> >
> >       message-header = field-name ":" [ field-value ]
> >       field-value    = *( field-content | LWS )
> >       field-content  = <the OCTETs making up the field-value
> >                        and consisting of either *TEXT or combinations
> >                        of token, separators, and quoted-string>
> >
> >       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
> >       quoted-pair    = "\" CHAR
> >       CHAR           = <any US-ASCII character (octets 0 - 127)>
> >
> >So, yes, one can have LF in the header if it is backquoted inside a
> >quoted string. Note that TEXT definition does not allow for CRLF
> >inside TEXT, only as a header termination/continuation.
> >
> >Said that, I doubt many HTTP agents can handle backquoted new line
> >correctly.
> >
> >Alex.
> >
> >
> >
> >
> >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/

On Wed, 31 Oct 2001 darin@... wrote:

> in my experiences, web servers often mix \r\n and \n line endings in the
> header section.  as a result, it is common to ignore \r and only look
> for \n.

Yes, and doing so is explicitly recommended by HTTP:

    The line terminator for message-header fields is the sequence CRLF.
    However, we recommend that applications, when parsing such headers,
    recognize a single LF as a line terminator and ignore the leading CR.

though use of bare CR or LF is explicitly prohibited by HTTP:

    a bare CR or LF MUST NOT be substituted for CRLF within any of the
    HTTP control structures (such as header fields and multipart
    boundaries).

The usual IETF's garbage-in-treasure-out stuff...

I do not think this is related to the "can I have /n in any of the
header?" question. I think Aniruddha is trying to put \n inside the
*value* of an HTTP header field. I may be misinterpreting the original
question though...

Alex.

> Alex Rousskov wrote:
>
> >On Wed, 31 Oct 2001, Aniruddha Shevade wrote:
> >
> >> I am new to HTTP, and so please excuse me if this is a very basic
> >>question. Teh Http specification says that each HTTP header should
> >>be terminated by a CRLF i.e /r/n . Does this mean that I cannot
> >>have /n in any of the header .  Is There a way I can say that the
> >>\n in the header is not the terminator and just a part of the
> >>header data. This is required for me to test my HTTP parsing
> >>program
> >>
> >>Any help is appreciated
> >>
> >
> >The answer seems to be in HTTP specs:
> >
> >       message-header = field-name ":" [ field-value ]
> >       field-value    = *( field-content | LWS )
> >       field-content  = <the OCTETs making up the field-value
> >                        and consisting of either *TEXT or combinations
> >                        of token, separators, and quoted-string>
> >
> >       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
> >       quoted-pair    = "\" CHAR
> >       CHAR           = <any US-ASCII character (octets 0 - 127)>
> >
> >So, yes, one can have LF in the header if it is backquoted inside a
> >quoted string. Note that TEXT definition does not allow for CRLF
> >inside TEXT, only as a header termination/continuation.
> >
> >Said that, I doubt many HTTP agents can handle backquoted new line
> >correctly.
> >
> >Alex.
> >
> >
> >
> >
> >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/
> >
> >
>
>

On Wed, 31 Oct 2001, Aniruddha Shevade wrote:

 I am new to HTTP, and so please excuse me if this is a very basic
question. Teh Http specification says that each HTTP header should
be terminated by a CRLF i.e /r/n . Does this mean that I cannot
have /n in any of the header . Is There a way I can say that the
\n in the header is not the terminator and just a part of the
header data. This is required for me to test my HTTP parsing
program

Any help is appreciated

The answer seems to be in HTTP specs:

 message-header = field-name ":" [ field-value ]
 field-value = *( field-content | LWS )
 field-content = <the OCTETs making up the field-value
 and consisting of either *TEXT or combinations
 of token, separators, and quoted-string>

 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
 quoted-pair = "\" CHAR
 CHAR = <any US-ASCII character (octets 0 - 127)>

So, yes, one can have LF in the header if it is backquoted inside a
quoted string. Note that TEXT definition does not allow for CRLF
inside TEXT, only as a header termination/continuation.

Said that, I doubt many HTTP agents can handle backquoted new line
correctly.

Alex.



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!
http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/CefplB/TM
---------------------------------------------------------------------~->

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/ 

On Wed, 31 Oct 2001, Aniruddha Shevade wrote:

>  I am new to HTTP, and so please excuse me if this is a very basic
> question. Teh Http specification says that each HTTP header should
> be terminated by a CRLF i.e /r/n . Does this mean that I cannot
> have /n in any of the header .  Is There a way I can say that the
> \n in the header is not the terminator and just a part of the
> header data. This is required for me to test my HTTP parsing
> program
>
> Any help is appreciated

The answer seems to be in HTTP specs:

        message-header = field-name ":" [ field-value ]
        field-value    = *( field-content | LWS )
        field-content  = <the OCTETs making up the field-value
                         and consisting of either *TEXT or combinations
                         of token, separators, and quoted-string>

        quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
        quoted-pair    = "\" CHAR
        CHAR           = <any US-ASCII character (octets 0 - 127)>

So, yes, one can have LF in the header if it is backquoted inside a
quoted string. Note that TEXT definition does not allow for CRLF
inside TEXT, only as a header termination/continuation.

Said that, I doubt many HTTP agents can handle backquoted new line
correctly.

Alex.

Hello
  I am new to HTTP, and so please excuse me if this is a very basic question.
Teh Http specification says that each HTTP header should be terminated by a
CRLF
i.e /r/n   . Does this mean that I cannot have /n in any of the header .  Is
There a way I can say that the \n in the header is not the terminator and
just a part of the header
data. This is required  for me to test my HTTP parsing program

Any help is appreciated
thanks
-Aniruddha

This is a stretch for here, but is anyone aware of any implementations of
the SNMP WWW MIB using the "net-snmp" package, and if so, is the
implementation open-source, or has viewable source code?  I'm getting some
help from the "net-snmp-users" list, but I'm looking for additional
resources.  In particular, I'm trying to register string indexes for each of
the HTTP request method types, and I'm unable to figure out exactly how that
works.  If there's an existing implementation of the WWW MIB using
"net-snmp", they probably had to do similar things.

How do browsers figure out a response is "Complete" if the origin server
doesn't send a "Content-Length" header?  What is the normal strategy for
that?  The response could be sent in more than one packet, correct?


To unsubscribe from this group, send an email to:
http-compliance-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .