From a_kilman at berkeley.edu  Mon Oct  1 23:03:59 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Mon, 01 Oct 2007 23:03:59 -0700
Subject: [ee122] HW 2 - Question 3 General question
Message-ID: <1191305039.6898.6.camel@zerocool>

The prompt says that latency is 12ms. If I remember correctly, latency
is the delay in a network for 1 packet to get from point A to point B.

Now, if the bandwidth is 12Mbps, wouldn't the latency (per packet) be:

( 1500bytes * 8bits/byte ) / ( 12*10^6 bits / sec ) = 1ms

My confusion arose because I see that a latency is given, but there are
two different packet sizes. The regular one and the ACK. So I figure the
smaller one should be faster.. maybe I'm missing something?

Thanks in advance.

Anthony


From vern at cs.berkeley.edu  Mon Oct  1 23:55:42 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Mon, 01 Oct 2007 23:55:42 -0700
Subject: [ee122] HW 2 - Question 3 General question
In-Reply-To: <1191305039.6898.6.camel@zerocool> (Mon,
	01 Oct 2007 23:03:59 PDT).
Message-ID: <200710020655.l926tlmc001213@pork.ICSI.Berkeley.EDU>

> The prompt says that latency is 12ms. If I remember correctly, latency
> is the delay in a network for 1 packet to get from point A to point B.

When latency is given without mention of a packet size, then it's synonymous
to proagation delay: i.e., the time it takes for a signal (which you can
think of as a single bit) to get from point A to point B.  This value is
not affected by the bandwidth of the path.

		Vern

From vern at cs.berkeley.edu  Tue Oct  2 23:26:12 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Tue, 02 Oct 2007 23:26:12 -0700
Subject: [ee122] meta-announcement
Message-ID: <200710030626.l936QHvp029705@pork.ICSI.Berkeley.EDU>

We've updated a number of announcements at

	http://inst.eecs.berkeley.edu/%7Eee122/fa07/announcements.html

In particular, phase 2 of Project #1 is now out, as are solutions to
homework #1.

		Vern

From huntingtonsurfca at gmail.com  Wed Oct  3 00:30:20 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Wed, 3 Oct 2007 00:30:20 -0700
Subject: [ee122] HW1 Solutions - Question 3
Message-ID: <ffcc7690710030030y7edbae6di6eb87e2b4f5741b3@mail.gmail.com>

My graph points are almost exactly one half of your (y) graph points. Why?
Because I used the shortest possible -RTT- for light as opposed to a one-way
shot.

This made more sense since you are subjecting the electronic signal to an
RTT as well.

So do I get full credit? It doesn't specify anywhere that this was a one way
trip and my graph utimately looks like the one in the solutions, just half
as tall.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071003/3de36ede/attachment.html 

From fowler at eecs.berkeley.edu  Wed Oct  3 00:37:15 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Wed, 3 Oct 2007 00:37:15 -0700
Subject: [ee122] HW1 Solutions - Question 3
In-Reply-To: <ffcc7690710030030y7edbae6di6eb87e2b4f5741b3@mail.gmail.com>
References: <ffcc7690710030030y7edbae6di6eb87e2b4f5741b3@mail.gmail.com>
Message-ID: <330471bf0710030037p518fecbeh6af3577f48b6fc04@mail.gmail.com>

Hi Rick and others-

Specific questions about grading and individual scores for the
homework assignment (HW1) should be directed to Jorge ideally during
his office hours, and if you can't make them at all, via email.

Thanks,

-Lisa

On 10/3/07, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> My graph points are almost exactly one half of your (y) graph points. Why?
> Because I used the shortest possible -RTT- for light as opposed to a one-way
> shot.
>
> This made more sense since you are subjecting the electronic signal to an
> RTT as well.
>
> So do I get full credit? It doesn't specify anywhere that this was a one way
> trip and my graph utimately looks like the one in the solutions, just half
> as tall.
>
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>

From vern at cs.berkeley.edu  Wed Oct  3 07:22:39 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 03 Oct 2007 07:22:39 -0700
Subject: [ee122] HW1 Solutions - Question 3
In-Reply-To: <ffcc7690710030030y7edbae6di6eb87e2b4f5741b3@mail.gmail.com> (Wed,
	03 Oct 2007 00:30:20 PDT).
Message-ID: <200710031422.l93EMi6g012434@pork.ICSI.Berkeley.EDU>

For grading questions, (1) please don't send them to the list, as they're
unlikely to be of general interest, and (2) please first wait to pick up
your graded problem to see how your answer was treated.

		Vern

From vern at cs.berkeley.edu  Wed Oct  3 18:37:48 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 03 Oct 2007 18:37:48 -0700
Subject: [ee122] midterm review on Friday
Message-ID: <200710040137.l941br6P024785@pork.ICSI.Berkeley.EDU>

As I mentioned at the end of lecture today, for Friday's review please send
me email if there are particular questions/topics you would like covered.
In the absence of input, I will be going (quickly) through a many-slide
tour of what we've covered so far.

		Vern

From a_kilman at berkeley.edu  Wed Oct  3 20:49:38 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Wed, 03 Oct 2007 20:49:38 -0700
Subject: [ee122] hw2 prob6
Message-ID: <1191469778.8333.8.camel@zerocool>

Problem 6 specifies to submit a trace as documentation. After exporting
to ASCII via wireshark, it was huge. Should we just submit a transcript
of the commands?

I'm assuming it says this because this question was from Fall 2006 and
we're turning in a hard copy.


From vern at icir.org  Wed Oct  3 20:53:07 2007
From: vern at icir.org (Vern Paxson)
Date: Wed, 03 Oct 2007 20:53:07 -0700
Subject: [ee122] hw2 prob6
In-Reply-To: <1191469778.8333.8.camel@zerocool> (Wed,
	03 Oct 2007 20:49:38 PDT).
Message-ID: <200710040353.l943rCdd027833@pork.ICSI.Berkeley.EDU>

> Problem 6 specifies to submit a trace as documentation. After exporting
> to ASCII via wireshark, it was huge.

The trace shouldn't be that huge.  Please send it to me off-list so I can
see what's up with that.

		Vern

From vern at cs.berkeley.edu  Wed Oct  3 21:06:20 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 03 Oct 2007 21:06:20 -0700
Subject: [ee122] correction for Homework 2 Problem 6(b)
Message-ID: <200710040406.l9446Pia028055@pork.ICSI.Berkeley.EDU>

It turns out that the eecs.berkeley.edu mail servers *do* allow relaying
from the instructional machines.  So for this part, you should instead
try to send mail to a recipient of <vern at icir.org> via calmail.berkeley.edu
(which is where the MX record for berkeley.edu points).

		Vern

From vern at cs.berkeley.edu  Wed Oct  3 21:39:19 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 03 Oct 2007 21:39:19 -0700
Subject: [ee122] Homework #2 update
Message-ID: <200710040439.l944dOTg028682@pork.ICSI.Berkeley.EDU>

Per the question that Anthony Kilman raised regarding turning in hardcopy
of traces, for your homework you should submit output from *tshark*, not
Wireshark (which is much more verbose).

I've updated Homework #2 to state this, and also to include the use of
calmail.berkeley.edu rather than an eecs.berkeley.edu mail server for the
relaying part of problem 5:

	http://inst.eecs.berkeley.edu/%7Eee122/fa07/hw/hw2.pdf

(same URL as before)

- Vern

From a_kilman at berkeley.edu  Wed Oct  3 23:25:41 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Wed, 03 Oct 2007 23:25:41 -0700
Subject: [ee122] Question out of curiousity #7
Message-ID: <1191479141.15853.4.camel@zerocool>

I'm running Ubuntu 7.04 on my laptop. I ran the reverse look up for the
IP we're supposed to find in part B. On my machine I get an error: (not
the actual domain name I "dug")

; <<>> DiG 9.3.4 <<>> 12.34.56.78.in-addr.arpa
;; global options:  printcmd
;; connection timed out; no servers could be reached

Then I ssh into pulsar.cs.berkeley.edu, run the exact same command and
it works.. just curious as to why that might happen. Dig worked for the
rest of the problem on my machine, and this didn't..

Thanks in advance.


From vern at icir.org  Wed Oct  3 23:35:08 2007
From: vern at icir.org (Vern Paxson)
Date: Wed, 03 Oct 2007 23:35:08 -0700
Subject: [ee122] Question out of curiousity #7
In-Reply-To: <1191479141.15853.4.camel@zerocool> (Wed,
	03 Oct 2007 23:25:41 PDT).
Message-ID: <200710040635.l946ZD8n030838@pork.ICSI.Berkeley.EDU>

> ; <<>> DiG 9.3.4 <<>> 12.34.56.78.in-addr.arpa
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached

Part of the question directs you regarding which servers you should try.
The output above suggests you ran it without an @server argument.

		Vern

From huntingtonsurfca at gmail.com  Wed Oct  3 23:32:47 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Wed, 3 Oct 2007 23:32:47 -0700
Subject: [ee122] Follow up on the Problem about SNW vs. Sliding Window
Message-ID: <ffcc7690710032332l61f8d2a0mfa174934ba819e0d@mail.gmail.com>

I've come across two definitions of bandwidth-delay product in my search for
answers, one of which uses the on-way delay and another which uses the RTT
delay.

I looked in the book and they use the <d sub prop> and is interpeted as one
way delay. (HW1 [p.73 P.18])

But that means that the sliding window, if using the BDP, has to wait almost
an entire window transmission (more actually while the rec transmits an ACK)
before it can move the window one packet iota. But if the BDP is using the
RTT (as I was thinking), then it is much more ideal (and the problem goes
back to that lost millisecond I mentioned earlier... well... one packet
transmission +  one ACK transmission time per burst).

So what should I use? The results are gonna be a bit different.

Thanks,
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071003/94cda17e/attachment.html 

From vern at icir.org  Wed Oct  3 23:43:08 2007
From: vern at icir.org (Vern Paxson)
Date: Wed, 03 Oct 2007 23:43:08 -0700
Subject: [ee122] Follow up on the Problem about SNW vs. Sliding Window
In-Reply-To: <ffcc7690710032332l61f8d2a0mfa174934ba819e0d@mail.gmail.com> (Wed,
	03 Oct 2007 23:32:47 PDT).
Message-ID: <200710040643.l946hD1g031010@pork.ICSI.Berkeley.EDU>

> I've come across two definitions of bandwidth-delay product in my search for
> answers, one of which uses the on-way delay and another which uses the RTT
> delay.
> 
> I looked in the book and they use the <d sub prop> and is interpeted as one
> way delay. (HW1 [p.73 P.18])

This is a good point to clarify.

P18 in HW1 was emphasizing what it takes to fill a link, and in that case
(since no feedback from acks is needed to keep the process going [by sliding
the window]), the one-way delay suffices.

However, for sliding window, the delay waiting for the acks to arrive is
a critical element.  Thus, when considering transport performance, you
need to use the RTT rather than the one-way time.  (In addition, for a
precise calculation this RTT needs to account for both the propagation
time and the transmission time.  This latter will be different in the two
directions if the data being sent differs in size from the acknowledgments
being returned to slide the window.)  By the way, this case of considering
the RTT is the usual use of bandwidth-delay product.

		Vern

From pavyedav at berkeley.edu  Thu Oct  4 13:43:29 2007
From: pavyedav at berkeley.edu (Pavan Yedavalli)
Date: Thu, 4 Oct 2007 13:43:29 -0700
Subject: [ee122] Midterm Review Question
Message-ID: <8ec15b790710041343n1c529d62h8dbaf833c125653c@mail.gmail.com>

Professor Paxson,

Could you give an example in class of an entire communication system,
starting at application layer of the source and then ending at the
application layer of the destination, describing everything that the packet
of data does or goes through in the middle? I'm sure you were planning that
anyways, but I think a good overview of all the concepts and layers in one
particular example would be great reinforcement.

Also, I found TCP/IP to be confusing (namely the assigning of addresses and
how the source and destination know of those addresses.) Thanks.

-- 
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071004/80d32b89/attachment.html 

From fowler at eecs.berkeley.edu  Fri Oct  5 17:28:37 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Fri, 5 Oct 2007 17:28:37 -0700
Subject: [ee122] Midterm Review - Cory 531 - Tues 11-12:30p
Message-ID: <330471bf0710051728o313e4d54tfe539c2564b05d5e@mail.gmail.com>

Jorge, Daniel, and I will be holding a special review section for the
Oct 12 Midterm.  This review section will take place in Cory 531 (Wang
Room) on Tues Oct 9 from 11am-12:30pm.

NOTE:   This is in lieu of Daniel's regular office hours.  Come to
Cory 531 instead!

We are also available for extra office hours by appointment next week.

-Lisa

From ericcheung at berkeley.edu  Sat Oct  6 16:30:16 2007
From: ericcheung at berkeley.edu (Eric Cheung)
Date: Sat, 06 Oct 2007 16:30:16 -0700
Subject: [ee122] Project 1b error codes
Message-ID: <47081A88.3090004@berkeley.edu>

For the HTTP/1.0 400 errors, the spec doesn't list "spurious token 
before CRLF" as one of the errors, as it was in part a.  Is this a 
mistake or should those errors be included in "invalid http-version token"?

Also, assuming we're still using greedy matching, when returning the 
corresponding offending token, should we just return the rest of the 
request that doesn't match or just the rest of the request up to the 
next space?
e.g.
should it be:
GETa /index.html HTTP/1.0 --> Invalid Request-URI token: a /index.html 
HTTP/1.0
or:
GETa /index.html HTTP/1.0 --> Invalid Request-URI token: a

and

should it be:
GET /index.html~~~~ HTTP/1.0 --> Invalid Request-URI token: /index.html~~~~
or
GET /index.html~~~~ HTTP/1.0 --> Invalid Request-URI token: 
/index.html~~~~ HTTP/1.0

Thanks
- Eric

From nescionomen at gmail.com  Sat Oct  6 17:32:59 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Sat, 6 Oct 2007 17:32:59 -0700
Subject: [ee122]  bandwidth delay product
Message-ID: <ee4042d90710061732k1c23fbd9pe88409beb6d6e0f3@mail.gmail.com>

Seems there are two definitions.  In one, the capacity of the data link is
multiplied with the end to end delay, in another, the capacity of the data
link is multiplied with the RTT.  Which one should we use during a test?
IIRC, the first homework had us use the end to end delay, whereas the second
homework has us use the RTT latency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071006/91c40c27/attachment.html 

From nescionomen at gmail.com  Sat Oct  6 17:50:30 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Sat, 6 Oct 2007 17:50:30 -0700
Subject: [ee122] bandwidth delay product ooops
Message-ID: <ee4042d90710061750r68cd9195l45d7036af8e99fbe@mail.gmail.com>

Nevermind, this was already answered...  I just didn't remember because it
was answered long ago in an e-mail that at the time I didn't really digest
since I hadn't reached that part of the homework yet.  Ooops, sorry.

On 10/6/07, Nescio Nomen <nescionomen at gmail.com> wrote:
>
> Seems there are two definitions.  In one, the capacity of the data link is
> multiplied with the end to end delay, in another, the capacity of the data
> link is multiplied with the RTT.  Which one should we use during a test?
> IIRC, the first homework had us use the end to end delay, whereas the second
> homework has us use the RTT latency.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071006/a613d321/attachment.html 

From lingchen at berkeley.edu  Sun Oct  7 00:25:15 2007
From: lingchen at berkeley.edu (Ling Chen)
Date: Sun, 07 Oct 2007 00:25:15 -0700
Subject: [ee122]  hw2 problem2 tracefile
Message-ID: <470889DB.5000003@berkeley.edu>

In the hw, it says to submit a hard copy of the tracefile as tshark 
output, not Wireshark output...
What does that mean? How do we get a tshark output? I translated the 
tracefile through Wireshark and it was pretty long.
Any one know?

Ling

From vern at icir.org  Sun Oct  7 21:28:26 2007
From: vern at icir.org (Vern Paxson)
Date: Sun, 07 Oct 2007 21:28:26 -0700
Subject: [ee122] hw2 problem2 tracefile
In-Reply-To: <470889DB.5000003@berkeley.edu> (Sun, 07 Oct 2007 00:25:15 PDT).
Message-ID: <200710080428.l984SVSk007041@pork.ICSI.Berkeley.EDU>

> What does that mean? How do we get a tshark output?

tshark is a tracing program that comes with the Wireshark package.
It's similar to tcpdump, generating ASCII summaries of packets rather
than visualizing them.  You can access it on the instructional accounts
from /share/b/ee122/{i86pc,sun4u}/bin/ (same place as wireshark).

		Vern

From vern at icir.org  Sun Oct  7 23:19:44 2007
From: vern at icir.org (Vern Paxson)
Date: Sun, 07 Oct 2007 23:19:44 -0700
Subject: [ee122] Project 1b error codes
In-Reply-To: <47081A88.3090004@berkeley.edu> (Sat, 06 Oct 2007 16:30:16 PDT).
Message-ID: <200710080619.l986JnQt008339@pork.ICSI.Berkeley.EDU>

> e.g.
> should it be:
> GETa /index.html HTTP/1.0 --> Invalid Request-URI token: a /index.html 
> HTTP/1.0
> or:
> GETa /index.html HTTP/1.0 --> Invalid Request-URI token: a
> 
> and
> 
> should it be:
> GET /index.html~~~~ HTTP/1.0 --> Invalid Request-URI token: /index.html~~~~
> or
> GET /index.html~~~~ HTTP/1.0 --> Invalid Request-URI token: 
> /index.html~~~~ HTTP/1.0

Any of these are fine (except if in the last one you mean to introduce a
newline, you should avoid that, as it makes it harder to grade).  It would
also be fine for the first example to instead say "Invalid Request-Method".

Basically, there needs to be an error message and it needs to correctly
point out a problem with the line, but that's it.

		Vern

From ofer at berkeley.edu  Tue Oct  9 18:10:10 2007
From: ofer at berkeley.edu (Ofer Sadgat)
Date: Tue, 9 Oct 2007 18:10:10 -0700
Subject: [ee122] HTTP Questions
Message-ID: <000e01c80ada$510db420$f3291c60$@edu>

I've used my old client to get pages from servers and not all have the
"Content-Length" header. www.google.com for example. What is the protocol
regarding this possibility?

 

If I wanted to implement all of the functionality of dig, how would I do
this? Is there a simple protocall spec somewhere?

 

Also, what is the wireshark command to do the tcpdump, I tried it with the
same arguments as tcpdump but it didn't work.

 

Thanks,

Ofer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071009/0d74fb91/attachment.html 

From huntingtonsurfca at gmail.com  Tue Oct  9 23:59:51 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Tue, 9 Oct 2007 23:59:51 -0700
Subject: [ee122] Solutions to past midterms?
Message-ID: <ffcc7690710092359u214d6404m66053fde0052bfa3@mail.gmail.com>

HKN only seems to have 1 midterm of Prof. Paxson's, and there are no
solutions.

Has anyone found any of his midterms with solutions? Can we link them? I
didn't find one on the website either.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071009/4c050b65/attachment.html 

From dank at berkeley.edu  Thu Oct 11 01:39:41 2007
From: dank at berkeley.edu (Daniel Killebrew)
Date: Thu, 11 Oct 2007 01:39:41 -0700
Subject: [ee122] Solutions to past midterms?
In-Reply-To: <ffcc7690710092359u214d6404m66053fde0052bfa3@mail.gmail.com>
References: <ffcc7690710092359u214d6404m66053fde0052bfa3@mail.gmail.com>
Message-ID: <470DE14D.5040500@berkeley.edu>



Richard Schmidt wrote:
> HKN only seems to have 1 midterm of Prof. Paxson's, and there are no 
> solutions.
>  
> Has anyone found any of his midterms with solutions? Can we link them? 
> I didn't find one on the website either.
I don't think any exist. If you have questions about particular 
problems, you can come to office hours and we can work out the problems. 
Lisa and I have OHs before fridays midterm.

Daniel
>  
> Rick
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From vern at cs.berkeley.edu  Wed Oct 10 13:45:18 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 10 Oct 2007 13:45:18 -0700
Subject: [ee122] solutions for homework #2
Message-ID: <200710102045.l9AKjNsU032293@pork.ICSI.Berkeley.EDU>

These are now available at

	http://inst.eecs.berkeley.edu/~ee122/fa07/hw/hw2-soln.pdf

- Vern & Daniel

From vern at cs.berkeley.edu  Wed Oct 10 13:49:18 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 10 Oct 2007 13:49:18 -0700
Subject: [ee122] Solutions to past midterms?
In-Reply-To: <ffcc7690710092359u214d6404m66053fde0052bfa3@mail.gmail.com> (Tue,
	09 Oct 2007 23:59:51 PDT).
Message-ID: <200710102049.l9AKnNVD032378@pork.ICSI.Berkeley.EDU>

They're available off of last year's web page:

	http://inst.eecs.berkeley.edu/~ee122/fa06/

Search the lecture schedule for "midterm".

		Vern

From a_kilman at berkeley.edu  Wed Oct 10 15:50:22 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Wed, 10 Oct 2007 15:50:22 -0700
Subject: [ee122] Clarification on a past midterm question
Message-ID: <1192056622.7284.3.camel@zerocool>

2. Framing.
Traditional Ethernet does not include a length field in its header.
Instead, it uses the absence of an electrical signal on the cable to
deduce the end of a frame.

    (a) Assuming that the physical layer encodes ?low? as the absence of
an electrical signal and ?high? as the presence of an electrical signal,
for which of the following encodings:

            i. NRZ (Non-Return to Zero)
           ii. NRZI (Non-Return to Zero Inverted)
          iii. Manchester
          iv.  4-bit/5-bit
         
might the Ethernet controller have difficulty determining the end of the
frame, and under what circumstances? Why not for the others? (8 pts)

My question is, are we still assuming we're referring to the same "high"
and "low" used to encode 0's & 1's, say like the NRZ? Or is this
information somehow encoded with the voltage on the line remaining above
a threshold that would consider it "high"?




From vern at cs.berkeley.edu  Wed Oct 10 21:12:34 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 10 Oct 2007 21:12:34 -0700
Subject: [ee122] Clarification on a past midterm question
In-Reply-To: <1192056622.7284.3.camel@zerocool> (Wed,
	10 Oct 2007 15:50:22 PDT).
Message-ID: <200710110412.l9B4Cdp6007029@pork.ICSI.Berkeley.EDU>

> My question is, are we still assuming we're referring to the same "high"
> and "low" used to encode 0's & 1's, say like the NRZ? Or is this
> information somehow encoded with the voltage on the line remaining above
> a threshold that would consider it "high"?

The former.  The point of this problem (which hopefully is apparent from
the solutions that I flagged earlier today) was to consider the problem
of "low" aliasing with "must be end of message, since there's no electrical
signal".  (It's a bit more than just NRZ's representation, since all of
the encoding schemes we've discussed have a notion of "low" vs. "high".
So for others, "low" might not be a 0-bit but instead encodes a bit - or
perhaps part of bit, for schemes like Manchester - which might be a 1-bit.)

		Vern

From vern at cs.berkeley.edu  Thu Oct 11 08:59:33 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Thu, 11 Oct 2007 08:59:33 -0700
Subject: [ee122] bug fix for solution to Homework #2 problem 3(d)
Message-ID: <200710111559.l9BFxcwS020950@pork.ICSI.Berkeley.EDU>

The original solutions had an error, which has now been fixed.  I've
appended diffs, and updated the PDF at the same URL as before.

My thanks to Rick Schmidt for spotting this, and apologies for not getting
it correct originally.

		Vern


Index: hw2_soln.tex
===================================================================
--- hw2_soln.tex	(revision 113)
+++ hw2_soln.tex	(working copy)
@@ -17,7 +17,11 @@
 
 \begin{centering}
 \begin{Large}
-Solutions for Homework \#2\\[0.2in]
+Solutions for Homework \#2\footnote{
+Version 2, Oct 11 2007: Fixes an incorrect solution for Problem 3(d).
+Our apologies, and kudos to Rick Schmidt for spotting the error.
+}
+\\[0.2in]
 \end{Large}
 
 \begin{large}
@@ -275,23 +279,38 @@
 	For a 122,000~byte file, this results in 3~full window's worth of
 	packets, followed by 6~more packets (the last of which is a partial
 	packet, again of size 820~bytes).
-	We employ the method used above to calculate the total transfer time
+
+	We might employ the method used above to calculate the total transfer time
 	and corresponding throughput. The 84$^{\mbox{th}}$ packet belongs
-	to the sequence \#6, \#32, \#58, \#84.  As established above, each
-	full-sized packet has a transmission time of 1~msec, so we will begin
-	transmission of packet \#6 at time 5~msec.
+	to the sequence \#6, \#32, \#58, \#84.  However, a subtlety arises,
+	as follows.  When the ACK for packet \#1 arrives, it allows us to
+	send packet \#27 (since the window is 26~packets in size).  Note that
+	this occurs \emph{while we are still in the process of transmitting
+	packet \#26}, because 26~packets represent a bit \emph{more} data
+	than required to keep the forward path continuously busy.
 
-	Packet \#84 will be sent 3 RTTs later:
-	$$
-		T_{84} = T_{6} + 3 \cdot~\mbox{RTT} = 5 + 3 \cdot 25.027 = 80.08~\mbox{ms}
-	$$
+	We can see this effect by considering that we start sending
+	packet \#26 at a time 25~msec after we began sending packet \#1
+	(since each packet has a transmission time of 1~msec).  We will
+	finish transmitting packet \#26 at time 26~msec.  However, the
+	RTT for this path is 25.027~msec.  Thus, the ACK arrives shortly
+	after we have \emph{begun} sending packet \#26, and before we
+	have finished doing so.
+
+	This means that we send packet \#27 directly after we finish sending
+	packet \#26, so at time 26~msec, rather than at time we would
+	calculate based on the RTT.
+
+	Therefore, a window of 26~packets means that every packet goes
+	out 1~msec after its predecessor.  In particular, we start sending
+	packet \#84 at time 83~msec.
 	The time required to transmit \#84 and receive its ACK added to the send
 	time of \#84 gives us the total transmission time:
 	$$
-		T_{84} + T_{\mbox{partial}} + T_{\mbox{ack}} = 104.681\mbox{ms}
+		T_{84} + T_{\mbox{partial}} + T_{\mbox{ack}} = 83 + 24.6 = 107.6\mbox{ms}
 	$$
-	Throughput is therefore $122000\mbox{B} / 104.681~\mbox{ms} =
-	1.165445~\mbox{MBps} = 9.32356~\mbox{Mbps}$.  It's not the full
+	Throughput is therefore $122000\mbox{B} / 107.6~\mbox{ms} =
+	1.133829~\mbox{MBps} = 9.070632~\mbox{Mbps}$.  It's not the full
 	12~Mbps because we spend about half an RTT waiting for the first
 	data packet to arrive at the receiver, and another half an RTT
 	waiting for the final ack to arrive back at the sender.

From vern at cs.berkeley.edu  Thu Oct 11 11:59:26 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Thu, 11 Oct 2007 11:59:26 -0700
Subject: [ee122] HTTP Questions
In-Reply-To: <000e01c80ada$510db420$f3291c60$@edu> (Tue,
	09 Oct 2007 18:10:10 PDT).
Message-ID: <200710111859.l9BIxVb5024587@pork.ICSI.Berkeley.EDU>

> I've used my old client to get pages from servers and not all have the
> "Content-Length" header. www.google.com for example. What is the protocol
> regarding this possibility?

If you're issuing an HTTP 1.0 request and don't include the keep-alive
option, then the server marks the end of its reply by closing the connection.

> If I wanted to implement all of the functionality of dig, how would I do
> this? Is there a simple protocall spec somewhere?

The nitty gritty of the DNS protocol is specified in RFC 1035.  dig has
to be able to construct such requests directly (rather than using a library
to do so) in order to fully control things like recursive/iterative, and
to have raw access to replies in order to dump them out.

> Also, what is the wireshark command to do the tcpdump, I tried it with the
> same arguments as tcpdump but it didn't work.

tshark is the component that comes with the Wireshark package for doing
tcpdump-style packet capture.  If instead you mean how do you get wireshark
to itself capture packets, there's a pull-down menu for this at the top
of the window; however, on the instructional machines this doesn't work
because wireshark can't be given the necessary permissions to access
the packet filter.

		Vern

From jde at berkeley.edu  Thu Oct 11 19:54:39 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Thu, 11 Oct 2007 19:54:39 -0700
Subject: [ee122] [EE122] Question on IP Fragmentation
Message-ID: <470EE1EF.5030307@berkeley.edu>

On slides 21, 22, and 23 of lecture 4, I noticed something confusing 
about the length field of fragment 1 (slide 21), and the offset of 
fragment 2 (slide 22). Shouldn't the offset of fragment 2 denote the 
location of where data should be concatenated in memory on the receiver? 
If so, I'm not sure why the length of frag 1 is 1496 and the offset of 
frag 2 is 1496. It would seem to me that, if the IP header were 20 
bytes, then the offset of frag 2 should be 1476, because the data of 
frag 1 was 1476 bytes long, (bytes 0 to 1475 in the receiving host's 
memory). Thus, frag 2's offset should be 1476, to denote where frag 2's 
data should start.

Thanks for any help I can get on understanding this!

Jonathan

From kedar at berkeley.edu  Thu Oct 11 21:06:53 2007
From: kedar at berkeley.edu (Kedar Kanitkar)
Date: Thu, 11 Oct 2007 21:06:53 -0700
Subject: [ee122] [EE122] Question on IP Fragmentation
In-Reply-To: <470EE1EF.5030307@berkeley.edu>
References: <470EE1EF.5030307@berkeley.edu>
Message-ID: <470EF2DD.4080702@berkeley.edu>

 From HW1 solutions. Chapter 4 P16:
"Note #1: the slides presented in lecture to illustrate fragmentation 
are wrong, for which Prof.
Paxson offers his apologies :-(."

Also, the grouping of data will have to be slightly different than what 
you stated below.  Since 1476 data bytes is not a multiple of 8, that's 
not a valid fragment; you'd have to use either 1472 or 1480 bytes (and 
therefore an offset of 184 or 185, respectively).

-Kedar

On 10/11/2007 7:54 PM, Jonathan D. Ellithorpe wrote:
> On slides 21, 22, and 23 of lecture 4, I noticed something confusing 
> about the length field of fragment 1 (slide 21), and the offset of 
> fragment 2 (slide 22). Shouldn't the offset of fragment 2 denote the 
> location of where data should be concatenated in memory on the receiver? 
> If so, I'm not sure why the length of frag 1 is 1496 and the offset of 
> frag 2 is 1496. It would seem to me that, if the IP header were 20 
> bytes, then the offset of frag 2 should be 1476, because the data of 
> frag 1 was 1476 bytes long, (bytes 0 to 1475 in the receiving host's 
> memory). Thus, frag 2's offset should be 1476, to denote where frag 2's 
> data should start.
>
> Thanks for any help I can get on understanding this!
>
> Jonathan
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From huntingtonsurfca at gmail.com  Fri Oct 12 14:22:58 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Fri, 12 Oct 2007 14:22:58 -0700
Subject: [ee122] UNIX and FileNameChar
Message-ID: <ffcc7690710121422t182e1ae6jc3f6e2c070e72e6f@mail.gmail.com>

The http protocol says that a valid file URI consists of:

Path = "/" *FileNameChar
FileNameChar = ALPHA | DIGIT | "." | "-" | " " | "/"

That means that a valid path could be:

/folder.root/newFolder.index.html/dir

If this is true, what is the file extension?
What is the directory that the client wished to access?

If I could have the answer to these two questions, I think I'd know
exactly how I am expected to implement these retrievals. Thank you.
Rick

From fowler at eecs.berkeley.edu  Fri Oct 12 14:30:51 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Fri, 12 Oct 2007 14:30:51 -0700
Subject: [ee122] UNIX and FileNameChar
In-Reply-To: <ffcc7690710121422t182e1ae6jc3f6e2c070e72e6f@mail.gmail.com>
References: <ffcc7690710121422t182e1ae6jc3f6e2c070e72e6f@mail.gmail.com>
Message-ID: <330471bf0710121430q2b0ce94avcf73c38ca8416cc@mail.gmail.com>

On 10/12/07, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> The http protocol says that a valid file URI consists of:
>
> Path = "/" *FileNameChar
> FileNameChar = ALPHA | DIGIT | "." | "-" | " " | "/"
>
> That means that a valid path could be:
>
> /folder.root/newFolder.index.html/dir
>
> If this is true, what is the file extension?

Great question.  Yes it is true.  The file extension is non-existent.

> What is the directory that the client wished to access?

If "dir" is a directory:  /folder.root/newFolder.index.html/dir/
If "dir" is a file:  /folder.root/newFolder.index.html/


I hope this helps!

-Lisa

> If I could have the answer to these two questions, I think I'd know
> exactly how I am expected to implement these retrievals. Thank you.
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From davide.cerri at gmail.com  Sat Oct 13 13:26:37 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Sat, 13 Oct 2007 13:26:37 -0700
Subject: [ee122] keep-alive
Message-ID: <e0b6c83b0710131326x70c9ca2ck1c0e339921c2746f@mail.gmail.com>

Hello,
I am having trouble to understand how to implement keep-alive. Precisely:
Lets say i create a server that talks on port 80.
when i first connect the client to port 80 of the server, the server
creates a new socket for me to talk. Then if as a client i try to talk
again to port 80 my server tells me that it already created a socket
for me and returns and error.

do i have to set my client to send messages to the port i was
assigned, or do i have to have the server redirect the message to the
correct file descriptor?



-- 
~/Davide Cerri

From dank at eecs.berkeley.edu  Sat Oct 13 13:41:15 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sat, 13 Oct 2007 13:41:15 -0700
Subject: [ee122] keep-alive
In-Reply-To: <e0b6c83b0710131326x70c9ca2ck1c0e339921c2746f@mail.gmail.com>
References: <e0b6c83b0710131326x70c9ca2ck1c0e339921c2746f@mail.gmail.com>
Message-ID: <47112D6B.70604@eecs.berkeley.edu>

The server and the client do the same thing they did in phase 1, except 
now, the server will not close the connection after sending the response 
to the client's first request. This way the client can send multiple 
requests without reconnecting for each. So the server and client are 
reusing the sockets they have already created.


Daniel

Davide Cerri wrote:
> Hello,
> I am having trouble to understand how to implement keep-alive. Precisely:
> Lets say i create a server that talks on port 80.
> when i first connect the client to port 80 of the server, the server
> creates a new socket for me to talk. Then if as a client i try to talk
> again to port 80 my server tells me that it already created a socket
> for me and returns and error.
>
> do i have to set my client to send messages to the port i was
> assigned, or do i have to have the server redirect the message to the
> correct file descriptor?
>
>
>
>   

From huntingtonsurfca at gmail.com  Sat Oct 13 19:38:22 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Sat, 13 Oct 2007 19:38:22 -0700
Subject: [ee122] Permissions
Message-ID: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>

There are different permissions for 3 types of groups in unix.

User / Group / Others

Asking "ls -l" in my working directory lists something like this:

-rw-------   1 ee122-bz ee122        406 Oct  7 19:33 Makefile

Where each '-' corresponds to a denied permission, and the others
correspond to particular rights (i.e. 'r' means read).

My question is this:

At first I thought that I was to use the "others" permission status to
determine whether or not someone can read my private/diary.html

But when I create a file, I noticed that none of them have this
permission flagged (nither r,w, or x).

Am I supposed to use this "others" portion to determine permission
status, and if so, do I need to use chmod to change read status for
"others"? I don't really know (yet) how to do this.

Thanks
Rick

PS (Quick Q)-> The specs do not say that if the server response is
anything but 200 OK, that the server should either close the
connection or keep it open. What is the correct behavior?

From ccowart at berkeley.edu  Sat Oct 13 20:42:12 2007
From: ccowart at berkeley.edu (Christopher Cowart)
Date: Sat, 13 Oct 2007 20:42:12 -0700
Subject: [ee122] Permissions
In-Reply-To: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>
References: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>
Message-ID: <20071014034212.GB1117@jobe.lan>

On Sat, Oct 13, 2007 at 07:38:22PM -0700, Richard Schmidt wrote:
> At first I thought that I was to use the "others" permission status to
> determine whether or not someone can read my private/diary.html
> 
> But when I create a file, I noticed that none of them have this
> permission flagged (nither r,w, or x).
> 
> Am I supposed to use this "others" portion to determine permission
> status, and if so, do I need to use chmod to change read status for
> "others"? I don't really know (yet) how to do this.

The prevailing wisdom in UNIX software is to let the OS figure it out
for you. You'll often see reports of vulnerabilities "can run arbitrary
code with the permissions of the user."

When you run a web server as httpd or www or ee122-cx, it should be able
to read files as follows:
-r--------  If it owns them.
dr-x------

-r--r-----  If the group matches any group to which the effective uid of
dr-xr-x---  the daemon belongs.                                          
           
-r--r--r--  Always.
dr-xr-xr-x

The reason you probably associate "web server" with "world-readable" is
that in many environments, you get a ~/public_html folder. In order for
the uid of the httpd process to read files in there, they generally do
need to be world-readable.

If the call to open returns -1 and sets errno, you can check it for a
permission denied value and return your 403. I think most other errors
that open may return are probably more appropriately labeled as 500
errors.

-- 
Chris Cowart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 824 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071013/ec1edb9b/attachment.bin 

From huntingtonsurfca at gmail.com  Sat Oct 13 23:14:26 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Sat, 13 Oct 2007 23:14:26 -0700
Subject: [ee122] Permissions
In-Reply-To: <20071014034212.GB1117@jobe.lan>
References: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>
	<20071014034212.GB1117@jobe.lan>
Message-ID: <ffcc7690710132314g65a3fd21t4074b02d4eea2099@mail.gmail.com>

Thanks for the input. I've never used errno.h but now I see that it
should be fairly straightforward to use.

I'm guessing that I can also use this method to detect if the file
exists by checking the errno for ENOENT? That'd be much cleaner than
what I'm doing right now.

Thanks again,
Rick

On 10/13/07, Christopher Cowart <ccowart at berkeley.edu> wrote:
> On Sat, Oct 13, 2007 at 07:38:22PM -0700, Richard Schmidt wrote:
> > At first I thought that I was to use the "others" permission status to
> > determine whether or not someone can read my private/diary.html
> >
> > But when I create a file, I noticed that none of them have this
> > permission flagged (nither r,w, or x).
> >
> > Am I supposed to use this "others" portion to determine permission
> > status, and if so, do I need to use chmod to change read status for
> > "others"? I don't really know (yet) how to do this.
>
> The prevailing wisdom in UNIX software is to let the OS figure it out
> for you. You'll often see reports of vulnerabilities "can run arbitrary
> code with the permissions of the user."
>
> When you run a web server as httpd or www or ee122-cx, it should be able
> to read files as follows:
> -r--------  If it owns them.
> dr-x------
>
> -r--r-----  If the group matches any group to which the effective uid of
> dr-xr-x---  the daemon belongs.
>
> -r--r--r--  Always.
> dr-xr-xr-x
>
> The reason you probably associate "web server" with "world-readable" is
> that in many environments, you get a ~/public_html folder. In order for
> the uid of the httpd process to read files in there, they generally do
> need to be world-readable.
>
> If the call to open returns -1 and sets errno, you can check it for a
> permission denied value and return your 403. I think most other errors
> that open may return are probably more appropriately labeled as 500
> errors.
>
> --
> Chris Cowart
>
>

From huntingtonsurfca at gmail.com  Sun Oct 14 01:42:25 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Sun, 14 Oct 2007 01:42:25 -0700
Subject: [ee122] What is the file type of something with no tag?
Message-ID: <ffcc7690710140142q7ae33c94if40f1b1831f33b45@mail.gmail.com>

We check to make sure that:

/folder/dir

could be a file (like Makefile).

Since that is the case, what should my type/subtype header say? I'm
guessing <text/plain> but mayeb we just don't include this header for
this type of file.

Thanks,
Rick

From fowler at eecs.berkeley.edu  Sun Oct 14 09:34:46 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Sun, 14 Oct 2007 09:34:46 -0700
Subject: [ee122] What is the file type of something with no tag?
In-Reply-To: <ffcc7690710140142q7ae33c94if40f1b1831f33b45@mail.gmail.com>
References: <ffcc7690710140142q7ae33c94if40f1b1831f33b45@mail.gmail.com>
Message-ID: <330471bf0710140934nd4a1bfbseadc5d2db18c71e4@mail.gmail.com>

Actually, I have the best answer for this:  Per the spec, you aren't
required to support/retrieve/return/handle files with no extensions.
:)

"Your server is only required to support directory listings and files
of types: .txt, .html, .gif, and .jpg. File types will be interpreted
from case-insensitive filename extensions."

Hooray!

-Lisa

On 10/14/07, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> We check to make sure that:
>
> /folder/dir
>
> could be a file (like Makefile).
>
> Since that is the case, what should my type/subtype header say? I'm
> guessing <text/plain> but mayeb we just don't include this header for
> this type of file.
>
> Thanks,
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From blwang at berkeley.edu  Sun Oct 14 12:40:03 2007
From: blwang at berkeley.edu (Ben Wang)
Date: Sun, 14 Oct 2007 12:40:03 -0700
Subject: [ee122] project 1 milestone 1 grade?
Message-ID: <fde9932a0710141240l69b04bdbx95b657c712e749a0@mail.gmail.com>

Hi all,
I was wondering if we are going to get our project 1 milestone 1 graded
before the second part is turned in so that we can fix any errors that's in
milestone 1. Thanks!

-- 
cheers

Ben Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071014/898c11a9/attachment.html 

From dank at eecs.berkeley.edu  Sun Oct 14 13:47:10 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sun, 14 Oct 2007 13:47:10 -0700
Subject: [ee122] Permissions
In-Reply-To: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>
References: <ffcc7690710131938i3e3b4302j804704dae1ede89b@mail.gmail.com>
Message-ID: <4712804E.8010904@eecs.berkeley.edu>



Richard Schmidt wrote:
> There are different permissions for 3 types of groups in unix.
>
> User / Group / Others
>
> Asking "ls -l" in my working directory lists something like this:
>
> -rw-------   1 ee122-bz ee122        406 Oct  7 19:33 Makefile
>
> Where each '-' corresponds to a denied permission, and the others
> correspond to particular rights (i.e. 'r' means read).
>
> My question is this:
>
> At first I thought that I was to use the "others" permission status to
> determine whether or not someone can read my private/diary.html
>
> But when I create a file, I noticed that none of them have this
> permission flagged (nither r,w, or x).
>
> Am I supposed to use this "others" portion to determine permission
> status, and if so, do I need to use chmod to change read status for
> "others"? I don't really know (yet) how to do this.
>   
The OS will enforce whether your server will be able to read the file or 
not, based on permissions. For your personal testing purposes, since you 
are running as ee122-bz, you can create a file, chmod it to deny read 
access to user, group, and all, and then test by letting your server try 
and open it.
> Thanks
> Rick
>
> PS (Quick Q)-> The specs do not say that if the server response is
> anything but 200 OK, that the server should either close the
> connection or keep it open. 
That's because it should do what it does when the response is 200 OK.

Daniel
> What is the correct behavior?
>   
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From vern at cs.berkeley.edu  Mon Oct 15 00:28:15 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Mon, 15 Oct 2007 00:28:15 -0700
Subject: [ee122] attending section
Message-ID: <200710150728.l9F7SK6G015891@pork.ICSI.Berkeley.EDU>

Folks, it's particularly important for you to attend section this week
(and for many of you, more often in general).  I'm close to done grading
the midterms and many students had considerable difficulty with problems 3 & 4,
on multiple HTTP transfers and on the performance of sliding window.  This
week in section the TAs will go over both these problems & the corresponding
solutions.

This is your chance to get these important core concepts fully understood ...

		Vern

From ericcheung at berkeley.edu  Mon Oct 15 15:52:20 2007
From: ericcheung at berkeley.edu (Eric Cheung)
Date: Mon, 15 Oct 2007 15:52:20 -0700
Subject: [ee122] Failure to overwrite file on client side
Message-ID: <4713EF24.1010607@berkeley.edu>

The spec says "If a file with the same name already exists, replace it". 
  If this is not possible due to permission issues, what's the format of 
the error message the client should print out?

Thanks
- Eric

From davide.cerri at gmail.com  Mon Oct 15 21:17:00 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Mon, 15 Oct 2007 21:17:00 -0700
Subject: [ee122] server behavior
Message-ID: <e0b6c83b0710152117n7e91290cg43c2d52b1899d055@mail.gmail.com>

hello TA's,
from a server's point of view, how do we handle a client that send
requests that are longer than the 2048 bytes, can we just discard the
message?

thanks

-- 
~/Davide Cerri

From dank at eecs.berkeley.edu  Mon Oct 15 23:07:07 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Mon, 15 Oct 2007 23:07:07 -0700
Subject: [ee122] server behavior
In-Reply-To: <e0b6c83b0710152117n7e91290cg43c2d52b1899d055@mail.gmail.com>
References: <e0b6c83b0710152117n7e91290cg43c2d52b1899d055@mail.gmail.com>
Message-ID: <4714550B.9060205@eecs.berkeley.edu>



Davide Cerri wrote:
> hello TA's,
> from a server's point of view, how do we handle a client that send
> requests that are longer than the 2048 bytes,
With dynamically allocated buffers.

Daniel
>  can we just discard the
> message?
>
> thanks
>
>   

From vern at cs.berkeley.edu  Mon Oct 15 23:21:41 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Mon, 15 Oct 2007 23:21:41 -0700
Subject: [ee122] midterm & project #1 announcements
Message-ID: <200710160621.l9G6Lkeg006660@pork.ICSI.Berkeley.EDU>

The following are now all discussed and linked to from the course
Announcements page:

(1) The midterms are graded and solutions are available at

	http://inst.eecs.berkeley.edu/%7Eee122/fa07/notes/midterm-soln.pdf

    The exam proved fairly difficult, with a median score of 108.5 out of 150.
    You can pick up your graded exams in section.

(2) Reference implementations for the Phase 1 client and server, written
    by Daniel, are now available from

	http://inst.eecs.berkeley.edu/%7Eee122/fa07/projects/Project1A-ref/

(3) I've postponed the due date for Project 1 one week, to 11PM on Monday
    October 29.

(4) The Phase 2 writeup has been updated to reflect (2) and (3) above.

- Vern

From jde at berkeley.edu  Tue Oct 16 20:12:42 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Tue, 16 Oct 2007 20:12:42 -0700
Subject: [ee122] [Project1B] Error Message Question
Message-ID: <47157DAA.30506@berkeley.edu>

When the spec says, "<text of exception message>" or "<text of error 
message>", are we allowed to fill this with whatever meaningful message 
we want? For instance,

"ERROR -- Incommunicable Error: Client tried to connect but messed up"

Jonathan

From dank at eecs.berkeley.edu  Tue Oct 16 22:56:45 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Tue, 16 Oct 2007 22:56:45 -0700
Subject: [ee122] [Project1B] Error Message Question
In-Reply-To: <47157DAA.30506@berkeley.edu>
References: <47157DAA.30506@berkeley.edu>
Message-ID: <4715A41D.5080001@eecs.berkeley.edu>

Yeah, that's what you want to do.
Unless it's one of the specific errors that we told you exactly what to 
print (some of the phase 1 errors).

Daniel

Jonathan D. Ellithorpe wrote:
> When the spec says, "<text of exception message>" or "<text of error 
> message>", are we allowed to fill this with whatever meaningful message 
> we want? For instance,
>
> "ERROR -- Incommunicable Error: Client tried to connect but messed up"
>
> Jonathan
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From ofer at berkeley.edu  Wed Oct 17 01:58:53 2007
From: ofer at berkeley.edu (Ofer Sadgat)
Date: Wed, 17 Oct 2007 01:58:53 -0700
Subject: [ee122] DNS over TCP
Message-ID: <000e01c8109b$f428a9a0$dc79fce0$@edu>

I've read on the internet that you can issue a DNS request over a TCP
connection. I have generated valid DNS data (equivalent to the data that
wireshark picks up for DNS packets with the exception of the ID field which
I have set to 0x0101) and connected to a DNS server on port 53 and
transmitted the data. The problem is that I don't get a response. Maybe the
framing is wrong?

 

I've read that public hotspots use DNS to exclude people from using the
internet. Isnt this a bad idea because people will still be able to go to
sites which their browser might have cached the ip for?

 

Thanks,

Ofer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071017/5fa15ab1/attachment.html 

From ericcheung at berkeley.edu  Wed Oct 17 14:10:06 2007
From: ericcheung at berkeley.edu (Eric Cheung)
Date: Wed, 17 Oct 2007 14:10:06 -0700
Subject: [ee122] Project 1b - what to turn in for wireshark lab
Message-ID: <47167A2E.90204@berkeley.edu>

I'm a little confused as to whether or not we should be submitting 
packet traces for the textbook part of the lab.  It says " when turning 
in this part of the project you need to include traces you captured 
yourself" underneath the textbook part on page 7 of the spec, but then 
it says on page 8 "For each of the additional steps (but not for the 
main Lab), include a text dump of the relevant lines from your trace 
files", which makes it seem like we shouldn't be submitting the traces 
from the textbook lab part.

- Eric

From vern at cs.berkeley.edu  Wed Oct 17 15:40:39 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 17 Oct 2007 15:40:39 -0700
Subject: [ee122] DNS over TCP
In-Reply-To: <000e01c8109b$f428a9a0$dc79fce0$@edu> (Wed,
	17 Oct 2007 01:58:53 PDT).
Message-ID: <200710172240.l9HMeiXE024770@pork.ICSI.Berkeley.EDU>

> I've read on the internet that you can issue a DNS request over a TCP
> connection.

It is *optionally* supported.  So if the problem you're encountering is
that the server is rejecting the connection, it's because the server hasn't
chosen to support it.

The "dig" utility has a +tcp option that instructs it to use TCP rather
than UDP.  If you want to explore this further, first find a server that
works when using dig +tcp.  If your test code doesn't work for that server,
you can trace the traffic sent to the server by dig +tcp using tshark
(or tcpdump) and compare that with the traffic sent by your code to see
what's missing.

> I've read that public hotspots use DNS to exclude people from using the
> internet. Isnt this a bad idea because people will still be able to go to
> sites which their browser might have cached the ip for?

It will depend on how the hotspot does this.  (Often they instead intercept
HTTP requests, rather than DNS lookups.)  But usually a hotspot includes a
firewall that lets very little out until the MAC address has been associated
with some form of payment.  Interestingly, sometimes one of the few things
the firewall does let out are DNS requests, and in fact some enterprising
individuals have written tools that "tunnel" IP packets over DNS requests
as a way of getting service for free at such hotspots.  We'll talk more
about firewalls and tunneling later in the semester.

		Vern

From vern at cs.berkeley.edu  Thu Oct 18 00:16:44 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Thu, 18 Oct 2007 00:16:44 -0700
Subject: [ee122] Project 1b - what to turn in for wireshark lab
In-Reply-To: <47167A2E.90204@berkeley.edu> (Wed, 17 Oct 2007 14:10:06 PDT).
Message-ID: <200710180716.l9I7Gn1Z031596@pork.ICSI.Berkeley.EDU>

> I'm a little confused as to whether or not we should be submitting 
> packet traces for the textbook part of the lab.  It says " when turning 
> in this part of the project you need to include traces you captured 
> yourself" underneath the textbook part on page 7 of the spec, but then 
> it says on page 8 "For each of the additional steps (but not for the 
> main Lab), include a text dump of the relevant lines from your trace 
> files", which makes it seem like we shouldn't be submitting the traces 
> from the textbook lab part.

Oops, sorry that got muddled.  What was meant was that you turn in traces
you captured for the additional steps, but not for 1-19; and that while
it's fine to consult the textbook traces for 1-19, you should devise your
answers based on traces you yourself capture (even though for this part
you don't turn in those traces).

		Vern

From jde at berkeley.edu  Thu Oct 18 18:58:49 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Thu, 18 Oct 2007 18:58:49 -0700
Subject: [ee122] [Question] CR and Newline
Message-ID: <47180F59.4010502@berkeley.edu>

What is the difference between carriage return and newline?

Should we be worried about using \r\n as the CRLF sequence? I've read 
that C doesn't guarantee that \r and \n map to the ASCII LF and CR 
control characters.

Jonathan

From fowler at eecs.berkeley.edu  Thu Oct 18 19:06:47 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Thu, 18 Oct 2007 19:06:47 -0700
Subject: [ee122] [Question] CR and Newline
In-Reply-To: <47180F59.4010502@berkeley.edu>
References: <47180F59.4010502@berkeley.edu>
Message-ID: <330471bf0710181906o5a6b3be0haf1334006d07b092@mail.gmail.com>

On 10/18/07, Jonathan D. Ellithorpe <jde at berkeley.edu> wrote:
> What is the difference between carriage return and newline?
>
> Should we be worried about using \r\n as the CRLF sequence? I've read
> that C doesn't guarantee that \r and \n map to the ASCII LF and CR
> control characters.
>
> Jonathan

Hi Jonathan-

>From the RFC, in section 2.2, which is linked in the spec,

       CR            = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>

If you're worried about the \r and \n not mapping correctly, you can
use the ASCII representations.

A quick little wiki'ing says that "carriage return" historically moved
the printer "cursor" to the beginning of the line, whereas "line feed"
actually moves the paper, advancing the output to the next line.
Unfortunately the treatment of the two is inconsistent and often
causes problems (ever see lots of ^M's scattered through text
documents?)...  So, since the spec doth declare that you must use CRLF
per their definitions of CR and LF, thou shalt use those definitions.
:)

-Lisa

From ericcheung at berkeley.edu  Thu Oct 18 19:48:45 2007
From: ericcheung at berkeley.edu (Eric Cheung)
Date: Thu, 18 Oct 2007 19:48:45 -0700
Subject: [ee122] No content length or transfer encoding in http reply
Message-ID: <47181B0D.2090101@berkeley.edu>

If the client specifies a persistent connection and gets a reply without 
a content length or "transfer-encoding: chunking" in it, should it just 
close the connection?  Otherwise, the client wouldn't know when to stop 
reading.

Thanks
- Eric

From jde at berkeley.edu  Thu Oct 18 21:57:54 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Thu, 18 Oct 2007 21:57:54 -0700
Subject: [ee122] [Project1B] URI Question
Message-ID: <47183952.7090703@berkeley.edu>

The specification says that the client can send, as the last part of a URI:

/
foo/
foo/.
foo/..

I am wondering particularly about these dots '.' and ".."

1) Do 2 dots indicate a move back one directory?
2) If so, and if the client must already specify a full URI, why would 
the client ever use these dots if it could easily remove as many ending 
directories as there are dots before sending the GET request?
3) The maximum number of dots is 2?
4) Is it possible to have dots not at the end of a URI? For example: 
/home/etc/../crazy_dots/../../home/
5) Does a single dot mean anything?

Thanks!
Jonathan

From vern at cs.berkeley.edu  Thu Oct 18 22:19:20 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Thu, 18 Oct 2007 22:19:20 -0700
Subject: [ee122] [Question] CR and Newline
In-Reply-To: <47180F59.4010502@berkeley.edu> (Thu, 18 Oct 2007 18:58:49 PDT).
Message-ID: <200710190519.l9J5JPd3027435@pork.ICSI.Berkeley.EDU>

More generally, please do not worry about \r\n somehow not generating
the correct sequence.  This is not something we'll dig up an EBCDIC machine
with which to catch you up :-), and if \r\n doesn't generate the right
sequence then surely there's a ton of broken C network code out there ...
	
		Vern

From ccowart at berkeley.edu  Thu Oct 18 23:57:57 2007
From: ccowart at berkeley.edu (Christopher Cowart)
Date: Thu, 18 Oct 2007 23:57:57 -0700
Subject: [ee122] [Project1B] URI Question
In-Reply-To: <47183952.7090703@berkeley.edu>
References: <47183952.7090703@berkeley.edu>
Message-ID: <20071019065756.GH2199@jobe>

On Thu, Oct 18, 2007 at 09:57:54PM -0700, Jonathan D. Ellithorpe wrote:
> The specification says that the client can send, as the last part of a URI:
> 
> /
> foo/
> foo/.
> foo/..
> 
> I am wondering particularly about these dots '.' and ".."
> 
> 1) Do 2 dots indicate a move back one directory?
> 2) If so, and if the client must already specify a full URI, why would 
> the client ever use these dots if it could easily remove as many ending 
> directories as there are dots before sending the GET request?
> 3) The maximum number of dots is 2?
> 4) Is it possible to have dots not at the end of a URI? For example: 
> /home/etc/../crazy_dots/../../home/
> 5) Does a single dot mean anything?

. and .. are both valid directory names in Unix (And actually, Windows
and DOS do the right thing here too). You'll get them for free by just 
passing them along to the library functions.

.. means the parent directory
.  means the current directory

~/./foo/../bar == ~/bar

At your shell, try `ls -a'. They're always present, just hidden.

-- 
Chris Cowart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 824 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071018/58058261/attachment.bin 

From dank at eecs.berkeley.edu  Fri Oct 19 12:44:37 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Fri, 19 Oct 2007 12:44:37 -0700
Subject: [ee122] No content length or transfer encoding in http reply
In-Reply-To: <47181B0D.2090101@berkeley.edu>
References: <47181B0D.2090101@berkeley.edu>
Message-ID: <47190925.2050901@eecs.berkeley.edu>

A persistent connection has nothing to do with the reply coming in 
chunked or not. Persistent connection means the server won't close the 
connection after the file is sent.

But if you don't get a content length or chunked header line, you're 
free to gracefully close the connection and indicate the error to the user.

Daniel

Eric Cheung wrote:
> If the client specifies a persistent connection and gets a reply without 
> a content length or "transfer-encoding: chunking" in it, should it just 
> close the connection?  Otherwise, the client wouldn't know when to stop 
> reading.
>
> Thanks
> - Eric
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From a_kilman at berkeley.edu  Sat Oct 20 02:03:05 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Sat, 20 Oct 2007 02:03:05 -0700
Subject: [ee122] Question regarding permissions and Request-URI
Message-ID: <1192870985.28749.4.camel@zerocool>

Hello. Quick question.

Say, you have a request:

GET /foo/bar/dizzle/index.html

But the 'bar' directory's permissions forbid the "other" group from
reading it. I'm assuming that this would be a 'file not found'
situation, because I'd think to using the command line to find a file.
If this command can't even descend into the directory, we can't really
know the file even exists.. Is this thinking correct? Or is it a 403
error?

Thanks.

Anthony


From dank at eecs.berkeley.edu  Sun Oct 21 14:14:01 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sun, 21 Oct 2007 14:14:01 -0700
Subject: [ee122] No content length or transfer encoding in http reply
In-Reply-To: <47190925.2050901@eecs.berkeley.edu>
References: <47181B0D.2090101@berkeley.edu>
	<47190925.2050901@eecs.berkeley.edu>
Message-ID: <471BC119.3030307@eecs.berkeley.edu>

Important change to what I said earlier, read on:

Daniel Killebrew wrote:
> A persistent connection has nothing to do with the reply coming in 
> chunked or not. Persistent connection means the server won't close the 
> connection after the file is sent.
>
> But if you don't get a content length or chunked header line, you're 
> free to gracefully close the connection and indicate the error to the user.
>   
Actually, if the server does not include a content length or chunked 
header line, the client should assume that the server will send the file 
and close the connection after sending the last byte of the file. So the 
client will take everything after the HTTP header and save it as the file.

Professor Paxson pointed out:
The reasoning behind this is, if the client says it wants a persistent 
connection,
the server can *decline*. In that case, it can return an item with no
content-length and no chunking and it's not an error, so the client in
that case shouldn't close the connection when it sees the absence of either
of those headers; it should read the item up to an end-of-file.

Daniel
> Daniel
>
> Eric Cheung wrote:
>   
>> If the client specifies a persistent connection and gets a reply without 
>> a content length or "transfer-encoding: chunking" in it, should it just 
>> close the connection?  Otherwise, the client wouldn't know when to stop 
>> reading.
>>
>> Thanks
>> - Eric
>> _______________________________________________
>> ee122 mailing list
>> ee122 at mailman.ICSI.Berkeley.EDU
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>>
>>   
>>     
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From huntingtonsurfca at gmail.com  Sun Oct 21 22:01:51 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Sun, 21 Oct 2007 22:01:51 -0700
Subject: [ee122] Sentinels and Data
Message-ID: <ffcc7690710212201i4286efdfud8bc9cb2c759a85b@mail.gmail.com>

We saw on the midterm that there may be a problem using sentinels to
know where the end of data is.

Although, I'm pretty sure of the answer, I'd like to know if we have
to run through the data while we are sending it to make sure that
there are no character sequences that match a premature (in data)
CRLF.

I believe the answer is no, not for this project, so perhaps a more
general response can be provided.

Do they denote the data containing premature sentinels with something
like %<# of CR>%<# of LF>? I think I've seen this system used before
(especially for spaces). Do we have to implement a similar scheme? It
would seem unlikely then that a client would know how to decode these
symbols then.

Thanks,
Rick

From vern at cs.berkeley.edu  Sun Oct 21 22:20:11 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sun, 21 Oct 2007 22:20:11 -0700
Subject: [ee122] Sentinels and Data
In-Reply-To: <ffcc7690710212201i4286efdfud8bc9cb2c759a85b@mail.gmail.com> (Sun,
	21 Oct 2007 22:01:51 PDT).
Message-ID: <200710220520.l9M5KGxG025044@pork.ICSI.Berkeley.EDU>

> Although, I'm pretty sure of the answer, I'd like to know if we have
> to run through the data while we are sending it to make sure that
> there are no character sequences that match a premature (in data)
> CRLF.

If you reflect on how your client gets its input, it should be clear that
there's no opportunity for the input to itself contain an *embedded* CRLF,
since the mere presence of the CRLF will terminate the item of input
directly.

For your server when sending an item, reflecting on the means by which the
server frames the item (either chunking or content-length) likewise shows
that there isn't a problem with CRLF sentinels appearing in the item itself.

> Do they denote the data containing premature sentinels with something
> like %<# of CR>%<# of LF>?

That's indeed how they would be embedded.  But the writeup doesn't ask you
to support these.

		Vern

From blwang at berkeley.edu  Mon Oct 22 01:31:29 2007
From: blwang at berkeley.edu (Ben Wang)
Date: Mon, 22 Oct 2007 01:31:29 -0700
Subject: [ee122] spurious text question
Message-ID: <fde9932a0710220131t65a8fdadv18f4a41b0c578306@mail.gmail.com>

Hi all,
in the new specs, it seems that the spurious text error is never
mentioned. I was wondering how we should be handling this? Thanks!

-- 
cheers

Ben Wang

From nescionomen at gmail.com  Mon Oct 22 18:33:47 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Mon, 22 Oct 2007 18:33:47 -0700
Subject: [ee122]  error checking
Message-ID: <ee4042d90710221833h33c8a943ta4082283a81c0b59@mail.gmail.com>

So the client sends a get request to the server, the server sends a response
back.  Do we have to verify that the response makes perfect sense, eg their
HTTP version matches our own, the status code matches the phrase (eg 200 =
OK)?  The specs don't say to do any error checking on the response so if
it's not a big deal I'd just rather parse it as if it's correct and focus on
more important things.  If the response is nonsense, it'll probably be
detectable most of the time anyway, eg a regexp will probably not find the
status number, and so you can just reject the response.  If we do have to do
the kind of error checking I mentioned earlier, should it be classified as a
parsing error?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071022/b15da697/attachment.html 

From dank at eecs.berkeley.edu  Mon Oct 22 20:49:27 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Mon, 22 Oct 2007 20:49:27 -0700
Subject: [ee122] proj1a grades submitted
Message-ID: <471D6F47.80904@eecs.berkeley.edu>

Check your score with glookup.
I will be emailing everyone the individual score breakdown/which test 
cases passed & failed probably by tomorrow (tuesday) night. I will send 
the email to your ee122-xx at imail  account.


Daniel

From minhhtran at berkeley.edu  Tue Oct 23 15:08:59 2007
From: minhhtran at berkeley.edu (minhhtran at berkeley.edu)
Date: Tue, 23 Oct 2007 15:08:59 -0700 (PDT)
Subject: [ee122] Project1B - flex, bison ok?
Message-ID: <4578.169.229.127.45.1193177339.squirrel@calmail.berkeley.edu>

Hello,

According to the Notes section of the project specs, lex and yacc are
allowed.  Can we use similar tools that are available on inst machines (ie
c199), particularly flex and GNU bison?

Thanks,
-- 
Minh Tran


From vern at cs.berkeley.edu  Tue Oct 23 15:41:14 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Tue, 23 Oct 2007 15:41:14 -0700
Subject: [ee122] Project1B - flex, bison ok?
In-Reply-To: <4578.169.229.127.45.1193177339.squirrel@calmail.berkeley.edu>
	(Tue, 23 Oct 2007 15:08:59 PDT).
Message-ID: <200710232241.l9NMfJWM010469@pork.ICSI.Berkeley.EDU>

> According to the Notes section of the project specs, lex and yacc are
> allowed.  Can we use similar tools that are available on inst machines (ie
> c199), particularly flex and GNU bison?

Yes, that's fine.  Those tools are essentially equivalent.

		Vern

From simtan at berkeley.edu  Tue Oct 23 20:36:38 2007
From: simtan at berkeley.edu (Simon Tan)
Date: Tue, 23 Oct 2007 20:36:38 -0700
Subject: [ee122] Failure to overwrite file on client side
In-Reply-To: <4713EF24.1010607@berkeley.edu>
References: <4713EF24.1010607@berkeley.edu>
Message-ID: <op.t0omzcgi2hrgma@simthinkpad.gateway.2wire.net>

To follow up on this, I would like to point attention to the following  
line in the spec, in the section "Client Behavior":

If the request does not succeed, your client should print the status code  
and associated text, such as:
403 Forbidden: /secret/diary.html

This doesn't make much sense, since the HTTP headers should have already  
been printed. (A little earlier in that section, the spec says to print  
the response message to standard output. A 403 Foribidden would have been  
part of that response message.)

Also, if this is somehow referring to what happens when a client runs into  
permission issues when trying to *save* data to a file, why would the  
client be printing "403 Forbidden" to the user? And why would the client  
be trying to save a filename like "/secret/diary.html", when it really  
should be trying to save a file named "diary.html" (everything after the  
last '/'.)?

My main question is really reiterating what Eric asked below...


On Mon, 15 Oct 2007 15:52:20 -0700, Eric Cheung <ericcheung at berkeley.edu>  
wrote:

> The spec says "If a file with the same name already exists, replace it".
>   If this is not possible due to permission issues, what's the format of
> the error message the client should print out?
>
> Thanks
> - Eric
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122



-- 
~Simon Tan >> undergraduate at UC Berkeley
Source: simtan at berkeley.edu
Posting to both the mailing list and the newsgroup. Let's see if this  
works.

From nescionomen at gmail.com  Tue Oct 23 22:30:14 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Tue, 23 Oct 2007 22:30:14 -0700
Subject: [ee122]  question about file names
Message-ID: <ee4042d90710232230t25c62f17re885570735d09ce6@mail.gmail.com>

Once the client has retrieved an item from the server (via a 200 OK reply),
it constructs a local file name
into which to store the item. The new file name is the simple name of the
URI, i.e., all the characters
following the last '/'. This handles all but a few special cases. In these
special cases, your client must create
these files according the simple names listed below.
/ In this case, the simple name will be dir
foo/ In this case, the simple name will be foo

I don't understand that case.  What's it supposed to catch?

Is foo just a generic variable that stands for "any and all characters
before the last slash?"

So, for this request URI:

/database/contents/

foo would be:

/database/contents

Is that correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071023/fa06c8a2/attachment.html 

From dank at eecs.berkeley.edu  Wed Oct 24 05:13:54 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 24 Oct 2007 05:13:54 -0700
Subject: [ee122] question about file names
In-Reply-To: <ee4042d90710232230t25c62f17re885570735d09ce6@mail.gmail.com>
References: <ee4042d90710232230t25c62f17re885570735d09ce6@mail.gmail.com>
Message-ID: <471F3702.1050200@eecs.berkeley.edu>

Nescio Nomen wrote:
> Once the client has retrieved an item from the server (via a 200 OK 
> reply), it constructs a local file name
> into which to store the item. The new file name is the simple name of 
> the URI, i.e., all the characters
> following the last '/'. This handles all but a few special cases. In 
> these special cases, your client must create
> these files according the simple names listed below.
> / In this case, the simple name will be dir
> foo/ In this case, the simple name will be foo
>
> I don't understand that case. What's it supposed to catch?
>
> Is foo just a generic variable that stands for "any and all characters 
> before the last slash?"
>
> So, for this request URI:
>
> /database/contents/
>
> foo would be:
>
> /database/contents
 From the spec:
The new file name is the simple name of the URI, i.e., all the characters
following the last ?/?.

therefore '/database/' is not part of "all the characters following the 
last /"
so 'contents' would be the filename.

Please rid a bit more closely before asking questions.

Daniel
>
> Is that correct?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   


From nescionomen at gmail.com  Wed Oct 24 13:42:16 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Wed, 24 Oct 2007 13:42:16 -0700
Subject: [ee122] question about file names
In-Reply-To: <471F3702.1050200@eecs.berkeley.edu>
References: <ee4042d90710232230t25c62f17re885570735d09ce6@mail.gmail.com>
	<471F3702.1050200@eecs.berkeley.edu>
Message-ID: <ee4042d90710241342t56858479l2c27b9ccf46a6dd5@mail.gmail.com>

Sorry, maybe I am just being dumb.  Your claim is that the filename should
be "contents", based on the following rule: "The new file name is the simple
name of the URI, i.e., all the characters following the last '/'".  Since
the URI is /database/contents/, there is nothing actually following the the
last '/'.  Based on this, I do not see why the filename should be
"contents", at least not based on the rule you cite.  I am going to give you
the benefit of the doubt and assume you read my e-mail carefully.  If this
is true, you must be using a different idea of 'last' than me, or in an
alternative context where it actually refers to the second to last.  If this
is the case, the write up is definitely not clear and I would like a further
elaboration.

To reiterate, I don't know quite what to make of the following list of
'special cases':

/ In this case, the simple name will be dir
foo/ In this case, the simple name will be foo
foo/. In this case, the simple name will be dot
foo/.. In this case, the simple name will be dotdot

I was assuming, though not with absolute certainty, that these exceptions
refer to the entire URI, i.e. if the URI is just "/", the file name is
"dir."  However, it's not quite clear what foo/ means, since for a URI like
/database/contents/, it would seem the filename would be
"/database/contents" but that doesn't look quite right.  This is the
particular case I decided to check.  I thought it possible that instead the
filename might be merely "contents", based on the idea that "foo" was a
generic variable meant *only* as substitution for the last directory (in
which case the write up should have been explicit in specifying that "foo/"
was actually more like "/directory/directory/[...etc]/foo/."  But your
e-mail, while choosing the 2nd option, gives a completely different
explanation than I don't understand at all.  I'm really tired from all the
projects I'm working on concurrently and I'll admit I am not fully literate
at this point, but even so, I would opine that the write up and the
explanation you gave are not clear and that my question merits a more
detailed explanation.

On 10/24/07, Daniel Killebrew <dank at eecs.berkeley.edu> wrote:
>
> Nescio Nomen wrote:
> > Once the client has retrieved an item from the server (via a 200 OK
> > reply), it constructs a local file name
> > into which to store the item. The new file name is the simple name of
> > the URI, i.e., all the characters
> > following the last '/'. This handles all but a few special cases. In
> > these special cases, your client must create
> > these files according the simple names listed below.
> > / In this case, the simple name will be dir
> > foo/ In this case, the simple name will be foo
> >
> > I don't understand that case. What's it supposed to catch?
> >
> > Is foo just a generic variable that stands for "any and all characters
> > before the last slash?"
> >
> > So, for this request URI:
> >
> > /database/contents/
> >
> > foo would be:
> >
> > /database/contents
> From the spec:
> The new file name is the simple name of the URI, i.e., all the characters
> following the last '/'.
>
> therefore '/database/' is not part of "all the characters following the
> last /"
> so 'contents' would be the filename.
>
> Please rid a bit more closely before asking questions.
>
> Daniel
> >
> > Is that correct?
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071024/52da8607/attachment.html 

From dank at eecs.berkeley.edu  Wed Oct 24 15:47:39 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 24 Oct 2007 15:47:39 -0700
Subject: [ee122] question about file names
In-Reply-To: <ee4042d90710241342t56858479l2c27b9ccf46a6dd5@mail.gmail.com>
References: <ee4042d90710232230t25c62f17re885570735d09ce6@mail.gmail.com>
	<471F3702.1050200@eecs.berkeley.edu>
	<ee4042d90710241342t56858479l2c27b9ccf46a6dd5@mail.gmail.com>
Message-ID: <471FCB8B.9040700@eecs.berkeley.edu>

Without getting into a battle of words, here is the explanation:

Saving a file as /bar/foo means saving the file foo in the directory bar.
We don't want you guys to have to worry about making directories, 
putting files in them etc., just being able to create a file in the 
working directory is fine for the purposes of this project.
So your example request of /database/contents/ is saved as contents in 
this directory, not contents in the subdirectory of database/

Clear now I hope. If not let me know...

Daniel

Nescio Nomen wrote:
> Sorry, maybe I am just being dumb.  Your claim is that the filename 
> should be "contents", based on the following rule: "The new file name 
> is the simple name of the URI, i.e., all the characters following the 
> last '/'".  Since the URI is /database/contents/, there is nothing 
> actually following the the last '/'.  Based on this, I do not see why 
> the filename should be "contents", at least not based on the rule you 
> cite.  I am going to give you the benefit of the doubt and assume you 
> read my e-mail carefully.  If this is true, you must be using a 
> different idea of 'last' than me, or in an alternative context where 
> it actually refers to the second to last.  If this is the case, the 
> write up is definitely not clear and I would like a further elaboration.
>
> To reiterate, I don't know quite what to make of the following list of 
> 'special cases':
>
> / In this case, the simple name will be dir
> foo/ In this case, the simple name will be foo
> foo/. In this case, the simple name will be dot
> foo/.. In this case, the simple name will be dotdot
>
> I was assuming, though not with absolute certainty, that these 
> exceptions refer to the entire URI, i.e. if the URI is just "/", the 
> file name is "dir."  However, it's not quite clear what foo/ means, 
> since for a URI like /database/contents/, it would seem the filename 
> would be "/database/contents" but that doesn't look quite right.  This 
> is the particular case I decided to check.  I thought it possible that 
> instead the filename might be merely "contents", based on the idea 
> that "foo" was a generic variable meant *only* as substitution for the 
> last directory (in which case the write up should have been explicit 
> in specifying that "foo/" was actually more like 
> "/directory/directory/[...etc]/foo/."  But your e-mail, while choosing 
> the 2nd option, gives a completely different explanation than I don't 
> understand at all.  I'm really tired from all the projects I'm working 
> on concurrently and I'll admit I am not fully literate at this point, 
> but even so, I would opine that the write up and the explanation you 
> gave are not clear and that my question merits a more detailed 
> explanation. 
>
> On 10/24/07, *Daniel Killebrew* <dank at eecs.berkeley.edu 
> <mailto:dank at eecs.berkeley.edu>> wrote:
>
>     Nescio Nomen wrote:
>     > Once the client has retrieved an item from the server (via a 200 OK
>     > reply), it constructs a local file name
>     > into which to store the item. The new file name is the simple
>     name of
>     > the URI, i.e., all the characters
>     > following the last '/'. This handles all but a few special cases. In
>     > these special cases, your client must create
>     > these files according the simple names listed below.
>     > / In this case, the simple name will be dir
>     > foo/ In this case, the simple name will be foo
>     >
>     > I don't understand that case. What's it supposed to catch?
>     >
>     > Is foo just a generic variable that stands for "any and all
>     characters
>     > before the last slash?"
>     >
>     > So, for this request URI:
>     >
>     > /database/contents/
>     >
>     > foo would be:
>     >
>     > /database/contents
>     From the spec:
>     The new file name is the simple name of the URI, i.e., all the
>     characters
>     following the last '/'.
>
>     therefore '/database/' is not part of "all the characters
>     following the
>     last /"
>     so 'contents' would be the filename.
>
>     Please rid a bit more closely before asking questions.
>
>     Daniel
>     >
>     > Is that correct?
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > ee122 mailing list
>     > ee122 at mailman.ICSI.Berkeley.EDU
>     <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
>     > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>     <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122>
>     >
>
>

From dank at eecs.berkeley.edu  Wed Oct 24 16:06:18 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 24 Oct 2007 16:06:18 -0700
Subject: [ee122] error checking
In-Reply-To: <ee4042d90710221833h33c8a943ta4082283a81c0b59@mail.gmail.com>
References: <ee4042d90710221833h33c8a943ta4082283a81c0b59@mail.gmail.com>
Message-ID: <471FCFEA.40802@eecs.berkeley.edu>



Nescio Nomen wrote:
> So the client sends a get request to the server, the server sends a 
> response back.  Do we have to verify that the response makes perfect 
> sense, eg their HTTP version matches our own,
You can check that the HTTP version is 1.0 or 1.1. If it's not then it's 
fine with me if you classify it as a bad response.
> the status code matches the phrase (eg 200 = OK)?
You should check the code, the phrase is more for us humans.
> The specs don't say to do any error checking on the response so if 
> it's not a big deal I'd just rather parse it as if it's correct and 
> focus on more important things.  If the response is nonsense, it'll 
> probably be detectable most of the time anyway, eg a regexp will 
> probably not find the status number, and so you can just reject the 
> response.  
If you choose to keep parsing a response even if the HTTP version does 
not match 1.1 or 1.0, and you are able to parse the response and do 
something useful, that's also good.

Daniel
> If we do have to do the kind of error checking I mentioned earlier, 
> should it be classified as a parsing error?
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From dank at eecs.berkeley.edu  Wed Oct 24 16:12:54 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 24 Oct 2007 16:12:54 -0700
Subject: [ee122] Failure to overwrite file on client side
In-Reply-To: <op.t0omzcgi2hrgma@simthinkpad.gateway.2wire.net>
References: <4713EF24.1010607@berkeley.edu>
	<op.t0omzcgi2hrgma@simthinkpad.gateway.2wire.net>
Message-ID: <471FD176.5000102@eecs.berkeley.edu>



Simon Tan wrote:
> To follow up on this, I would like to point attention to the following  
> line in the spec, in the section "Client Behavior":
>
> If the request does not succeed, your client should print the status code  
> and associated text, such as:
> 403 Forbidden: /secret/diary.html
>
> This doesn't make much sense, since the HTTP headers should have already  
> been printed. (A little earlier in that section, the spec says to print  
> the response message to standard output. A 403 Foribidden would have been  
> part of that response message.)
>   
Print out the status code & associated text again (but not the whole 
header again), just to highlight to the user that an error occurred :)
> Also, if this is somehow referring to what happens when a client runs into  
> permission issues when trying to *save* data to a file, why would the  
> client be printing "403 Forbidden" to the user? And why would the client  
> be trying to save a filename like "/secret/diary.html", when it really  
> should be trying to save a file named "diary.html" (everything after the  
> last '/'.)?
>   
The server would not be sending such a message to the client, of course. 
(since the server doesn't know what the permissions are on the client's 
system)  The server is sending a 403 Forbidden: message because the 
client is not supposed to request the /secret/diary.html file (or at 
least the server shouldn't reply with the file because of permissions).

If the client is unable to save the file to disk because of permissions 
issues, print out a reasonable error message such as "ERROR -- could not 
save <filename> to disk".

Daniel
> My main question is really reiterating what Eric asked below...
>
>
> On Mon, 15 Oct 2007 15:52:20 -0700, Eric Cheung <ericcheung at berkeley.edu>  
> wrote:
>
>   
>> The spec says "If a file with the same name already exists, replace it".
>>   If this is not possible due to permission issues, what's the format of
>> the error message the client should print out?
>>
>> Thanks
>> - Eric
>> _______________________________________________
>> ee122 mailing list
>> ee122 at mailman.ICSI.Berkeley.EDU
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>>     
>
>
>
>   

From drewlustro at gmail.com  Thu Oct 25 21:06:12 2007
From: drewlustro at gmail.com (Drew Lustro)
Date: Thu, 25 Oct 2007 21:06:12 -0700
Subject: [ee122] proj1b reading files from current working directory??
Message-ID: <B8105F28-2313-448A-BAA8-B1260CD50147@gmail.com>

How do you find the current working directory of the process for  
http_server?

So like when you wanna get /foo.html how do you get

/Users/drew/Eclipse/ee122-Server/Debug/ as the current working  
directory (as a string) in order to then to concat foo.html ??

Drew


From fowler at eecs.berkeley.edu  Thu Oct 25 21:16:51 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Thu, 25 Oct 2007 21:16:51 -0700
Subject: [ee122] proj1b reading files from current working directory??
In-Reply-To: <B8105F28-2313-448A-BAA8-B1260CD50147@gmail.com>
References: <B8105F28-2313-448A-BAA8-B1260CD50147@gmail.com>
Message-ID: <330471bf0710252116y34f6ac03u4637c5bcbdcd4f8b@mail.gmail.com>

You can just use "." to access the current working directory.

-Lisa

On 10/25/07, Drew Lustro <drewlustro at gmail.com> wrote:
> How do you find the current working directory of the process for
> http_server?
>
> So like when you wanna get /foo.html how do you get
>
> /Users/drew/Eclipse/ee122-Server/Debug/ as the current working
> directory (as a string) in order to then to concat foo.html ??
>
> Drew
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From huntingtonsurfca at gmail.com  Thu Oct 25 21:18:38 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Thu, 25 Oct 2007 21:18:38 -0700
Subject: [ee122] proj1b reading files from current working directory??
In-Reply-To: <B8105F28-2313-448A-BAA8-B1260CD50147@gmail.com>
References: <B8105F28-2313-448A-BAA8-B1260CD50147@gmail.com>
Message-ID: <ffcc7690710252118k2f7108e3re117c5c564d7a14e@mail.gmail.com>

If you really want to use the full working directory:

popen("pwd", "r") --> returns a pipe-stream with the 'working
directory' (pwd is  a unix command for that).

If you want to, you can do what Lisa suggested (strcat-ing the request
to '.'), or you can just shave off the preceding '/' and Unix knows
what you're talking about.

Rick

On 10/25/07, Drew Lustro <drewlustro at gmail.com> wrote:
> How do you find the current working directory of the process for
> http_server?
>
> So like when you wanna get /foo.html how do you get
>
> /Users/drew/Eclipse/ee122-Server/Debug/ as the current working
> directory (as a string) in order to then to concat foo.html ??
>
> Drew
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From jeremyfleischman at gmail.com  Thu Oct 25 22:58:34 2007
From: jeremyfleischman at gmail.com (Jeremy Fleischman)
Date: Thu, 25 Oct 2007 22:58:34 -0700
Subject: [ee122] Buffering Server Response?
Message-ID: <5830e3770710252258t46e2a2aq97f13ca6d3c03f6b@mail.gmail.com>

 Is it alright if our client buffers the full response from the server
before we start writing to file? I see no problem with this except with
situations where the client is requesting really large files, which would
suck up our ram.

Jeremy Fleischman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071025/8fdb86d8/attachment.html 

From leeallen at berkeley.edu  Fri Oct 26 14:38:29 2007
From: leeallen at berkeley.edu (Allen Lee)
Date: Fri, 26 Oct 2007 14:38:29 -0700
Subject: [ee122] [Proj1b] index.html Question
Message-ID: <59f1e110710261438l181d206hd4e0bf037babede5@mail.gmail.com>

I have a question about what to print if we don't have read permission after
appending /index.html to the URI.  Suppose the server receives the request
"GET /foo HTTP/1.0" and successfully resolves the request by appending
/index.html to the URI.  If we don't have read permission for this file,
should the response be

HTTP/1.0 403 Forbidden: /foo

or

HTTP/1.0 403 Forbidden: /foo/index.html

Thanks,
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071026/379c9a24/attachment.html 

From fowler at eecs.berkeley.edu  Fri Oct 26 14:40:07 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Fri, 26 Oct 2007 14:40:07 -0700
Subject: [ee122] [Proj1b] index.html Question
In-Reply-To: <59f1e110710261438l181d206hd4e0bf037babede5@mail.gmail.com>
References: <59f1e110710261438l181d206hd4e0bf037babede5@mail.gmail.com>
Message-ID: <330471bf0710261440y5b74e65dgcbc01defaecafa30@mail.gmail.com>

HTTP/1.0 403 Forbidden: /foo  Would be sufficient.  That was the
request that the user made, and perhaps revealing that "/foo" was
translated to "/foo/index.html" might be revealing too much about your
system....

-Lisa

On 10/26/07, Allen Lee <leeallen at berkeley.edu> wrote:
> I have a question about what to print if we don't have read permission after
> appending /index.html to the URI.  Suppose the server receives the request
> "GET /foo HTTP/1.0" and successfully resolves the request by appending
> /index.html to the URI.  If we don't have read permission for this file,
> should the response be
>
> HTTP/1.0 403 Forbidden: /foo
>
> or
>
> HTTP/1.0 403 Forbidden: /foo/index.html
>
> Thanks,
> Allen
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>

From dank at eecs.berkeley.edu  Fri Oct 26 16:56:18 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Fri, 26 Oct 2007 16:56:18 -0700
Subject: [ee122] proj1a test cases
Message-ID: <47227EA2.3060601@eecs.berkeley.edu>

See my section webpage
http://inst.eecs.berkeley.edu/~ee122-tb/
for the test cases I used in proj1a

I will also post the testing scripts, but it will be your job to figure 
out how to run them if you want to. They're in perl so have fun with 
it... Also you will need the Expect package from CPAN.


Daniel

From dank at eecs.berkeley.edu  Fri Oct 26 17:00:20 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Fri, 26 Oct 2007 17:00:20 -0700
Subject: [ee122] Buffering Server Response?
In-Reply-To: <5830e3770710252258t46e2a2aq97f13ca6d3c03f6b@mail.gmail.com>
References: <5830e3770710252258t46e2a2aq97f13ca6d3c03f6b@mail.gmail.com>
Message-ID: <47227F94.6050607@eecs.berkeley.edu>

It would be better practice to start writing it to file. And probably 
easier to implement that way too, when you have to handle chunking.

Daniel

Jeremy Fleischman wrote:
> Is it alright if our client buffers the full response from the server 
> before we start writing to file? I see no problem with this except 
> with situations where the client is requesting really large files, 
> which would suck up our ram.
>  
> Jeremy Fleischman
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From jde at berkeley.edu  Fri Oct 26 22:08:31 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Fri, 26 Oct 2007 22:08:31 -0700
Subject: [ee122] Headers
Message-ID: <4722C7CF.2050205@berkeley.edu>

What delineates one header from another? like:

Bla1: bla-bla bla
Bla2: a lot more bla

Is it a newline character?

Thanks!
Jonathan

From vern at cs.berkeley.edu  Fri Oct 26 23:01:20 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Fri, 26 Oct 2007 23:01:20 -0700
Subject: [ee122] deadline for Project 1 phase 2 extended to Oct 31
Message-ID: <200710270601.l9R61P6K024277@pork.ICSI.Berkeley.EDU>

As announced in lecture today, I've decided to extend the deadline for
phase 2 of Project 1 to 11PM on Wednesday Oct 31.

		Vern

From vern at cs.berkeley.edu  Fri Oct 26 23:14:17 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Fri, 26 Oct 2007 23:14:17 -0700
Subject: [ee122] clarifications from today's lecture
Message-ID: <200710270614.l9R6EMKO024432@pork.ICSI.Berkeley.EDU>

There were two points that came up in today's lecture that I realized
I hadn't conveyed well enough.

(1) In TCP, *every* packet other than an initial SYN (which attempts to
    establish a new connection) contains an acknowledgment, which is
    indicated by setting the ACK bit in the "flags" field in the TCP header.
    In fact, if a TCP receives a non-initial-SYN packet that does not have
    ACK set, then it is required to discard it.

    The acknowledgment *always* reflects how far into the byte stream data
    has arrived *in sequence* (that is, no earlier missing segments) at
    the receiver who is sending the ACK.

    The sequence number associated with an acknowledgment is *always* a
    value 1 beyond the highest position in the byte stream that has arrived.

    For example, for the following segments, if the receiver generates
    a packet for each, then the righthand column gives the sequence number
    that would be present in the ACK (which every such packet will have):

	SYN (ISN = 105)		ACK=106  (105 + 1)
	data (106..115)		ACK=116
	data (115..143)		ACK=144
	data (160..180)		ACK=144  (can't be higher, since no more
					  in sequence)
	data (181..195)		ACK=144  (same as previous)
	data (144..159)		ACK=196  (now all data is in sequence)

(2) In TCP's processing, the initial steps look like:

	(a) Verify header length (must be >= 20 bytes) and checksum.
	    If either fails, *discard the packet* without any further
	    processing.

	(b) Look up the 4-tuple <IP source address, IP destination address,
	    TCP source port, TCP destination port> in the kernel's connection
	    table.

	(c) If no such connection exists, then
		(d) If the received packet has SYN set and does *not* have
		    ACK set
			(e) process it as an initial SYN attempting to
			    establish a connection
		*else*
		(f) send back a RST connection and forget about the packet,
		    since it belongs to a non-existent connection

Let me know if the above aren't clear ...

		Vern

From fowler at eecs.berkeley.edu  Sat Oct 27 00:42:39 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Sat, 27 Oct 2007 00:42:39 -0700
Subject: [ee122] Headers
In-Reply-To: <4722C7CF.2050205@berkeley.edu>
References: <4722C7CF.2050205@berkeley.edu>
Message-ID: <330471bf0710270042u3c968964wb6b0549aa19a5a78@mail.gmail.com>

The CRLF :)

On 10/26/07, Jonathan D. Ellithorpe <jde at berkeley.edu> wrote:
> What delineates one header from another? like:
>
> Bla1: bla-bla bla
> Bla2: a lot more bla
>
> Is it a newline character?
>
> Thanks!
> Jonathan
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From davide.cerri at gmail.com  Sat Oct 27 12:12:56 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Sat, 27 Oct 2007 12:12:56 -0700
Subject: [ee122] question about persistent connection
Message-ID: <e0b6c83b0710271212r1d81ed0dk1df93f777335ac13@mail.gmail.com>

Hello,
>Actually, if the server does not include a content length or chunked
>header line, the client should assume that the server will send the file
>and close the connection after sending the last byte of the file. So the
>client will take everything after the HTTP header and save it as the file.

I have a problem understanding how can we use the headers for chunking
and content length to tell us if a connection is closed. I mean, the
absence of those headers tell us we won't have a persistent connection
if we are sent a file. But what if we ask a persistent connection and
we request a file that is invalid. The server will politely reply

"HTTP/1.0 404 Not Found: /spam/is-tasty.html"

and no header will be sent to the client. Now is the connection
persistent or not? Because if i base my decision on the lack of
headers, that would imply that the server would close the connection
every time a client ask for an invalid file.
Wouldn't make sense for the server to always add a header to notify
the client that the connection is being kept alive?

can somebody explain persistent connection more precisely?

thanks
Davide Cerri








>Important change to what I said earlier, read on:
>
>Daniel Killebrew wrote:
>> A persistent connection has nothing to do with the reply coming in
>> chunked or not. Persistent connection means the server won't close the
>> connection after the file is sent.
>>
>> But if you don't get a content length or chunked header line, you're
>> free to gracefully close the connection and indicate the error to the user.
>>
>Actually, if the server does not include a content length or chunked
>header line, the client should assume that the server will send the file
>and close the connection after sending the last byte of the file. So the
>client will take everything after the HTTP header and save it as the file.
>
>Professor Paxson pointed out:
>The reasoning behind this is, if the client says it wants a persistent
>connection,
>the server can *decline*. In that case, it can return an item with no
>content-length and no chunking and it's not an error, so the client in
>that case shouldn't close the connection when it sees the absence of either
>of those headers; it should read the item up to an end-of-file.
>
>Daniel

-- 
~/Davide Cerri

From davide.cerri at gmail.com  Sat Oct 27 12:32:43 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Sat, 27 Oct 2007 12:32:43 -0700
Subject: [ee122] chunking
Message-ID: <e0b6c83b0710271232g7326b22ene12269c6b5810a2f@mail.gmail.com>

hello,
i hope this question hasn't already been asked.

In the case of chunking, does the client send an ACK after every
chunk? or does the server just send all the chunks in sequence and the
client just receive them all in sequence?

Thanks,

-- 
~/Davide Cerri

From dank at berkeley.edu  Sat Oct 27 13:01:54 2007
From: dank at berkeley.edu (Daniel Killebrew)
Date: Sat, 27 Oct 2007 13:01:54 -0700
Subject: [ee122] Server Handling Dot's
In-Reply-To: <9AF9ED7A-F030-497C-8F26-019D29AD9B26@berkeley.edu>
References: <9AF9ED7A-F030-497C-8F26-019D29AD9B26@berkeley.edu>
Message-ID: <47239932.3010506@berkeley.edu>

All of those should be treated as directories, except the one with 3 
dots since that's invalid.
Use the unix command 'ls' to guide you on whats a file and whats a 
directory.

Also the fopen() function returns an error, and the errno will be set to 
EISDIR if you tried to open a directory.


Daniel

Jeff Wang wrote:
> How is the server supposed to handle dots (".") in the URI?
>
> For example, if the URI is "/..", do we give the parent directory?
>
> How about:
>     "/foo/."
>     "/foo/../"
>     "/foo/../../"
>     "/foo/..."
>
> I don't the spec makes it clear since our regex in the pervious 
> milestone was very lenient.
> Right now, if there is a "." after the last "/", I'm just treating it 
> has a file.
>
> Thanks,
> Jeff Wang
>

From dank at berkeley.edu  Sat Oct 27 13:02:34 2007
From: dank at berkeley.edu (Daniel Killebrew)
Date: Sat, 27 Oct 2007 13:02:34 -0700
Subject: [ee122] Headers
In-Reply-To: <4722C7CF.2050205@berkeley.edu>
References: <4722C7CF.2050205@berkeley.edu>
Message-ID: <4723995A.7030604@berkeley.edu>

It's a single CRLF. Like so:

Bla1: bla-bla blaCRLFBla2: a lot more bla

Daniel

Jonathan D. Ellithorpe wrote:
> What delineates one header from another? like:
>
> Bla1: bla-bla bla
> Bla2: a lot more bla
>
> Is it a newline character?
>
> Thanks!
> Jonathan
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From dank at eecs.berkeley.edu  Sat Oct 27 13:09:52 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sat, 27 Oct 2007 13:09:52 -0700
Subject: [ee122] question about persistent connection
In-Reply-To: <e0b6c83b0710271212r1d81ed0dk1df93f777335ac13@mail.gmail.com>
References: <e0b6c83b0710271212r1d81ed0dk1df93f777335ac13@mail.gmail.com>
Message-ID: <47239B10.4050607@eecs.berkeley.edu>

I'm confused what you're trying to ask here.

The server will close the connection if it doesn't support persistent 
connections.


Davide Cerri wrote:
> Hello,
>   
>> Actually, if the server does not include a content length or chunked
>> header line, the client should assume that the server will send the file
>> and close the connection after sending the last byte of the file. So the
>> client will take everything after the HTTP header and save it as the file.
>>     
>
> I have a problem understanding how can we use the headers for chunking
> and content length to tell us if a connection is closed. I mean, the
> absence of those headers tell us we won't have a persistent connection
> if we are sent a file. 
> But what if we ask a persistent connection and
> we request a file that is invalid. The server will politely reply
>
> "HTTP/1.0 404 Not Found: /spam/is-tasty.html"
>
> and no header will be sent to the client.
The response indicates that there will be no file. If the server closes 
the connection after sending the response, obviously it doesn't support 
persistent connections. A blank line always follows the last header line.
>  Now is the connection
> persistent or not? Because if i base my decision on the lack of
> headers, that would imply that the server would close the connection
> every time a client ask for an invalid file.
> Wouldn't make sense for the server to always add a header to notify
> the client that the connection is being kept alive?
>   
Closing the connection notifies the client that the connection is not 
being kept alive...
> can somebody explain persistent connection more precisely?
>   
The point was this:
If a connection is persistent, the client needs to know where the end of 
a file is, and the beginning of the next response. So there must either 
be content-length or chunking to provide framing.
If it's not persistent then the client can assume that the connection 
will be closed after the last byte of the file is sent.

Daniel
> thanks
> Davide Cerri
>
>
>
>
>
>
>
>
>   
>> Important change to what I said earlier, read on:
>>
>> Daniel Killebrew wrote:
>>     
>>> A persistent connection has nothing to do with the reply coming in
>>> chunked or not. Persistent connection means the server won't close the
>>> connection after the file is sent.
>>>
>>> But if you don't get a content length or chunked header line, you're
>>> free to gracefully close the connection and indicate the error to the user.
>>>
>>>       
>> Actually, if the server does not include a content length or chunked
>> header line, the client should assume that the server will send the file
>> and close the connection after sending the last byte of the file. So the
>> client will take everything after the HTTP header and save it as the file.
>>
>> Professor Paxson pointed out:
>> The reasoning behind this is, if the client says it wants a persistent
>> connection,
>> the server can *decline*. In that case, it can return an item with no
>> content-length and no chunking and it's not an error, so the client in
>> that case shouldn't close the connection when it sees the absence of either
>> of those headers; it should read the item up to an end-of-file.
>>
>> Daniel
>>     
>
>   

From dank at eecs.berkeley.edu  Sat Oct 27 13:11:30 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sat, 27 Oct 2007 13:11:30 -0700
Subject: [ee122] chunking
In-Reply-To: <e0b6c83b0710271232g7326b22ene12269c6b5810a2f@mail.gmail.com>
References: <e0b6c83b0710271232g7326b22ene12269c6b5810a2f@mail.gmail.com>
Message-ID: <47239B72.9000903@eecs.berkeley.edu>

You may be confusing TCP and the application layer protocol we are 
running on top of TCP, in this case HTTP.

There is no ACKing in HTTP that I am aware of... TCP provides in order, 
reliable delivery for us.


Davide Cerri wrote:
> hello,
> i hope this question hasn't already been asked.
>
> In the case of chunking, does the client send an ACK after every
> chunk?
no
>  or does the server just send all the chunks in sequence and the
> client just receive them all in sequence?
>   
yes

Daniel
> Thanks,
>
>   

From jbw at berkeley.edu  Sat Oct 27 13:19:31 2007
From: jbw at berkeley.edu (jbw at berkeley.edu)
Date: Sat, 27 Oct 2007 13:19:31 -0700 (PDT)
Subject: [ee122]  HTTP Request Terminators
Message-ID: <2647.71.198.45.141.1193516371.squirrel@calmail.berkeley.edu>

I am wondering if we have to deal with client requests that have
a body or not.  If not we can check for the double CRLF since header
lines end in a CRLF and there is a CRLF at the end of the header
section.  If we do then we will have to read in the number of bytes from
the content-length header like we have to for persistent connections
on the client, so I am wondering which I should do.

Jon Whiteaker


From vern at cs.berkeley.edu  Sat Oct 27 13:22:31 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sat, 27 Oct 2007 13:22:31 -0700
Subject: [ee122] chunking
In-Reply-To: <47239B72.9000903@eecs.berkeley.edu> (Sat,
	27 Oct 2007 13:11:30 PDT).
Message-ID: <200710272022.l9RKMabQ005326@pork.ICSI.Berkeley.EDU>

> You may be confusing TCP and the application layer protocol we are 
> running on top of TCP, in this case HTTP.
> 
> There is no ACKing in HTTP that I am aware of... TCP provides in order, 
> reliable delivery for us.

Yep, well put.

		Vern

From vern at cs.berkeley.edu  Sat Oct 27 13:29:56 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sat, 27 Oct 2007 13:29:56 -0700
Subject: [ee122] question about persistent connection
In-Reply-To: <e0b6c83b0710271212r1d81ed0dk1df93f777335ac13@mail.gmail.com>
	(Sat, 27 Oct 2007 12:12:56 PDT).
Message-ID: <200710272030.l9RKU0rn005433@pork.ICSI.Berkeley.EDU>

> .... But what if we ask a persistent connection and
> we request a file that is invalid. The server will politely reply
> 
> "HTTP/1.0 404 Not Found: /spam/is-tasty.html"
> 
> and no header will be sent to the client.

A header *will* be sent.  The server responds according to the HTTP
spec, so with a version, status code, explanation, and then also
any additional headers the server wishes to send.

> Wouldn't make sense for the server to always add a header to notify
> the client that the connection is being kept alive?

Yes, and it does.

		Vern

From davide.cerri at gmail.com  Sat Oct 27 13:30:50 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Sat, 27 Oct 2007 13:30:50 -0700
Subject: [ee122] file permissions and file handling
Message-ID: <e0b6c83b0710271330o399fd9c5hb584242ecfc9581f@mail.gmail.com>

Hello,
I thought to use stat to check for the file information, but the man page show

#define S_IFMT 0170000           /* type of file */
     #define        S_IFIFO  0010000  /* named pipe (fifo) */
     #define        S_IFCHR  0020000  /* character special */
     #define        S_IFDIR  0040000  /* directory */
     #define        S_IFBLK  0060000  /* block special */
     #define        S_IFREG  0100000  /* regular */
     #define        S_IFLNK  0120000  /* symbolic link */
     #define        S_IFSOCK 0140000  /* socket */
     #define        S_IFWHT  0160000  /* whiteout */
     #define S_ISUID 0004000  /* set user id on execution */
     #define S_ISGID 0002000  /* set group id on execution */
     #define S_ISVTX 0001000  /* save swapped text even after use */
     #define S_IRUSR 0000400  /* read permission, owner */
     #define S_IWUSR 0000200  /* write permission, owner */
     #define S_IXUSR 0000100  /* execute/search permission, owner */

How can we check for world access?
I am assuming that we are allowed to send only world readable files to
the clients.

Also? the specs says that we only look for files starting from the web
server directory?
any hint on how to handle that? should we calculate that by parsing
the path and checking for ../ occurrences?

thanks,


-- 
~/Davide Cerri

From vern at cs.berkeley.edu  Sat Oct 27 13:31:27 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sat, 27 Oct 2007 13:31:27 -0700
Subject: [ee122] Server Handling Dot's
In-Reply-To: <47239932.3010506@berkeley.edu> (Sat, 27 Oct 2007 13:01:54 PDT).
Message-ID: <200710272031.l9RKVVaq005461@pork.ICSI.Berkeley.EDU>

> All of those should be treated as directories, except the one with 3 
> dots since that's invalid.

More precisely, 3 dots is simply a filename like any other.  '.' is a
filename that happens (under the hood in the Unix file system) to be linked
to the current directory, and '..' to the parent directory.

		Vern

From vern at cs.berkeley.edu  Sat Oct 27 13:32:28 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sat, 27 Oct 2007 13:32:28 -0700
Subject: [ee122] HTTP Request Terminators
In-Reply-To: <2647.71.198.45.141.1193516371.squirrel@calmail.berkeley.edu>
	(Sat, 27 Oct 2007 13:19:31 PDT).
Message-ID: <200710272032.l9RKWXQn005473@pork.ICSI.Berkeley.EDU>

> I am wondering if we have to deal with client requests that have
> a body or not.

You do not need to worry about the client request including a body, since
that's not legal for a GET method, which is the only one that the project
requires you to support.

		Vern

From davide.cerri at gmail.com  Sat Oct 27 13:44:16 2007
From: davide.cerri at gmail.com (Davide Cerri)
Date: Sat, 27 Oct 2007 13:44:16 -0700
Subject: [ee122] even more on file permissions
Message-ID: <e0b6c83b0710271344l2431634dxc334aacfb5183658@mail.gmail.com>

Hello,
if somebody had access to the server and created a link file, ex ln -s
/ evilfile, do we need to spot that somebody is using that file to
access the whole filesystem? or can we just let  it happen, because
anyway that is fault of a bad Sysadmin?

-- 
~/Davide Cerri

From dank at eecs.berkeley.edu  Sat Oct 27 17:10:17 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sat, 27 Oct 2007 17:10:17 -0700
Subject: [ee122] file permissions and file handling
In-Reply-To: <e0b6c83b0710271330o399fd9c5hb584242ecfc9581f@mail.gmail.com>
References: <e0b6c83b0710271330o399fd9c5hb584242ecfc9581f@mail.gmail.com>
Message-ID: <4723D369.80803@eecs.berkeley.edu>



Davide Cerri wrote:
> Hello,
> I thought to use stat to check for the file information, but the man page show
>
> #define S_IFMT 0170000           /* type of file */
>      #define        S_IFIFO  0010000  /* named pipe (fifo) */
>      #define        S_IFCHR  0020000  /* character special */
>      #define        S_IFDIR  0040000  /* directory */
>      #define        S_IFBLK  0060000  /* block special */
>      #define        S_IFREG  0100000  /* regular */
>      #define        S_IFLNK  0120000  /* symbolic link */
>      #define        S_IFSOCK 0140000  /* socket */
>      #define        S_IFWHT  0160000  /* whiteout */
>      #define S_ISUID 0004000  /* set user id on execution */
>      #define S_ISGID 0002000  /* set group id on execution */
>      #define S_ISVTX 0001000  /* save swapped text even after use */
>      #define S_IRUSR 0000400  /* read permission, owner */
>      #define S_IWUSR 0000200  /* write permission, owner */
>      #define S_IXUSR 0000100  /* execute/search permission, owner */
>
> How can we check for world access?
> I am assuming that we are allowed to send only world readable files to
> the clients.
>   
If I (ee122-tb) am executing your http_server, it will be running under 
my permissions. So it should be able to send out any files that ee122-tb 
can read. So the answer is no, it should send files that it is allowed 
to read. Unix will enforce the filesystem permissions. You need to 
determine whether to send a
403 Forbidden
or
404 Not Found
error to the client.
> Also? the specs says that we only look for files starting from the web
> server directory?
> any hint on how to handle that? should we calculate that by parsing
> the path and checking for ../ occurrences?
>   
That might work... Note that just counting the number of ../ occurrences 
is not quite a correct solution. As to why, I leave that to you to 
determine :)

Daniel

> thanks,
>
>
>   

From jde at berkeley.edu  Sat Oct 27 23:53:57 2007
From: jde at berkeley.edu (Jonathan D. Ellithorpe)
Date: Sat, 27 Oct 2007 23:53:57 -0700
Subject: [ee122] [Proj1b] index.html Question
In-Reply-To: <330471bf0710261440y5b74e65dgcbc01defaecafa30@mail.gmail.com>
References: <59f1e110710261438l181d206hd4e0bf037babede5@mail.gmail.com>
	<330471bf0710261440y5b74e65dgcbc01defaecafa30@mail.gmail.com>
Message-ID: <47243205.5020005@berkeley.edu>

There's also the question of, what if index.html doesn't have the 
permissions your need (silly, I know), but the directory in which it 
resides does have proper permissions...

In this case, would we return Forbidden or the contents of the readable 
directory?

More concretely:

foo = haha/zip/bang/

So we jump to step 2:
Step 2: try opening foo + index.html
 - if get access error, move on to step 3 (?)
Step 3: try opening foo
 - if get access error, tell client forbidden
 - else return contents of directory

Thanks!
Jonathan


Lisa Fowler wrote:
> HTTP/1.0 403 Forbidden: /foo  Would be sufficient.  That was the
> request that the user made, and perhaps revealing that "/foo" was
> translated to "/foo/index.html" might be revealing too much about your
> system....
>
> -Lisa
>
> On 10/26/07, Allen Lee <leeallen at berkeley.edu> wrote:
>   
>> I have a question about what to print if we don't have read permission after
>> appending /index.html to the URI.  Suppose the server receives the request
>> "GET /foo HTTP/1.0" and successfully resolves the request by appending
>> /index.html to the URI.  If we don't have read permission for this file,
>> should the response be
>>
>> HTTP/1.0 403 Forbidden: /foo
>>
>> or
>>
>> HTTP/1.0 403 Forbidden: /foo/index.html
>>
>> Thanks,
>> Allen
>>
>> _______________________________________________
>> ee122 mailing list
>> ee122 at mailman.ICSI.Berkeley.EDU
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>>
>>
>>     
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   


From fowler at eecs.berkeley.edu  Sun Oct 28 10:17:29 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Sun, 28 Oct 2007 10:17:29 -0700
Subject: [ee122] [Proj1b] index.html Question
In-Reply-To: <47243205.5020005@berkeley.edu>
References: <59f1e110710261438l181d206hd4e0bf037babede5@mail.gmail.com>
	<330471bf0710261440y5b74e65dgcbc01defaecafa30@mail.gmail.com>
	<47243205.5020005@berkeley.edu>
Message-ID: <330471bf0710281017y23284c49oa5438a24f689c2eb@mail.gmail.com>

This should all be handled by the OS for you, but the order should be:

If you can't read index.html, but you can read the directory,
permission is denied on haha/zip/bang .

If you can't read the directory, and you can't read index.html,
permission is denied on haha/zip/bang .

You only move forward through the steps if the file does not exist,
NOT if you don't have permission...

-Lisa

On 10/27/07, Jonathan D. Ellithorpe <jde at berkeley.edu> wrote:
> There's also the question of, what if index.html doesn't have the
> permissions your need (silly, I know), but the directory in which it
> resides does have proper permissions...
>
> In this case, would we return Forbidden or the contents of the readable
> directory?
>
> More concretely:
>
> foo = haha/zip/bang/
>
> So we jump to step 2:
> Step 2: try opening foo + index.html
>  - if get access error, move on to step 3 (?)
> Step 3: try opening foo
>  - if get access error, tell client forbidden
>  - else return contents of directory
>
> Thanks!
> Jonathan
>
>
> Lisa Fowler wrote:
> > HTTP/1.0 403 Forbidden: /foo  Would be sufficient.  That was the
> > request that the user made, and perhaps revealing that "/foo" was
> > translated to "/foo/index.html" might be revealing too much about your
> > system....
> >
> > -Lisa
> >
> > On 10/26/07, Allen Lee <leeallen at berkeley.edu> wrote:
> >
> >> I have a question about what to print if we don't have read permission after
> >> appending /index.html to the URI.  Suppose the server receives the request
> >> "GET /foo HTTP/1.0" and successfully resolves the request by appending
> >> /index.html to the URI.  If we don't have read permission for this file,
> >> should the response be
> >>
> >> HTTP/1.0 403 Forbidden: /foo
> >>
> >> or
> >>
> >> HTTP/1.0 403 Forbidden: /foo/index.html
> >>
> >> Thanks,
> >> Allen
> >>
> >> _______________________________________________
> >> ee122 mailing list
> >> ee122 at mailman.ICSI.Berkeley.EDU
> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >>
> >>
> >>
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
> >
>
>

From jkwang at berkeley.edu  Sun Oct 28 12:27:15 2007
From: jkwang at berkeley.edu (Jeff Wang)
Date: Sun, 28 Oct 2007 12:27:15 -0700
Subject: [ee122]  Content-Length vs. Actual File Size
Message-ID: <8769CE01-F53F-4F3E-BEE5-BA66120D6C0D@berkeley.edu>

How should we handle the case when the size of the data after header  
is longer (or shorter) than the Content-Length?

Which information should we trust?

From quang7721 at berkeley.edu  Sun Oct 28 13:01:16 2007
From: quang7721 at berkeley.edu (Tri Nguyen)
Date: Sun, 28 Oct 2007 13:01:16 -0700
Subject: [ee122] confuse on how to process data with chunked encoding
Message-ID: <f01a95d20710281301s4d52d658ja2f47df0c80564eb@mail.gmail.com>

here is the example from the spec:
HTTP/1.0 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
<blank line here>
200
<512 bytes of data, plus an additional CRLF>
1b
<27 bytes of data, plus an additional CRLF>
0
<blank line here>

I don't understand what 200 and 1b mean in this case
plus CRLF is an extra CRLF beside other CRLF in the 512 byte of data?
for example:
<blank line here>
200
<hello\r\n world\r\n\r\n> or <hello\r\n world\r\n>
1b
<27 bytes of data, plus an additional CRLF>
0
<blank line here>

thanks for any response
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071028/ee4617bf/attachment.html 

From dank at eecs.berkeley.edu  Sun Oct 28 15:14:55 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sun, 28 Oct 2007 15:14:55 -0700
Subject: [ee122] confuse on how to process data with chunked encoding
In-Reply-To: <f01a95d20710281301s4d52d658ja2f47df0c80564eb@mail.gmail.com>
References: <f01a95d20710281301s4d52d658ja2f47df0c80564eb@mail.gmail.com>
Message-ID: <472509DF.5030705@eecs.berkeley.edu>

Please read the RFC that is mentioned in the spec. It answers your question.

Daniel

Tri Nguyen wrote:
> here is the example from the spec:
> HTTP/1.0 200 OK
> Content-Type: text/html
> Transfer-Encoding: chunked
> <blank line here>
> 200
> <512 bytes of data, plus an additional CRLF>
> 1b
> <27 bytes of data, plus an additional CRLF>
> 0
> <blank line here>
>
> I don't understand what 200 and 1b mean in this case
> plus CRLF is an extra CRLF beside other CRLF in the 512 byte of data?
> for example:
> <blank line here>
> 200
> <hello\r\n world\r\n\r\n> or <hello\r\n world\r\n>
> 1b
> <27 bytes of data, plus an additional CRLF>
> 0
> <blank line here>
>
> thanks for any response
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From dank at eecs.berkeley.edu  Sun Oct 28 15:16:43 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sun, 28 Oct 2007 15:16:43 -0700
Subject: [ee122] Content-Length vs. Actual File Size
In-Reply-To: <8769CE01-F53F-4F3E-BEE5-BA66120D6C0D@berkeley.edu>
References: <8769CE01-F53F-4F3E-BEE5-BA66120D6C0D@berkeley.edu>
Message-ID: <47250A4B.1000206@eecs.berkeley.edu>

Trust the content-length.

If using a persistent connection:
Any data that's longer is part of the server's next response.
Non-persistent and theres extra data: ignore it

If data is ever shorter then you should be waiting for more.

Daniel

Jeff Wang wrote:
> How should we handle the case when the size of the data after header  
> is longer (or shorter) than the Content-Length?
>
> Which information should we trust?
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From ee122-dm at imail.EECS.Berkeley.EDU  Sun Oct 28 15:22:36 2007
From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU)
Date: Sun, 28 Oct 2007 15:22:36 -0700 (PDT)
Subject: [ee122] Fixing errors from part a
Message-ID: <60261.67.169.102.122.1193610156.squirrel@imail.eecs.berkeley.edu>

Hi, I was wondering how important it is to fix the errors (specifically
the interleaved requests and buffer allocation errors) from part a. About
how much of our grade will this be, since it would appear that part b
doesn't rely on this feature any more than a did?

Thanks,
Aaron


From dank at eecs.berkeley.edu  Sun Oct 28 15:26:18 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Sun, 28 Oct 2007 15:26:18 -0700
Subject: [ee122] Fixing errors from part a
In-Reply-To: <60261.67.169.102.122.1193610156.squirrel@imail.eecs.berkeley.edu>
References: <60261.67.169.102.122.1193610156.squirrel@imail.eecs.berkeley.edu>
Message-ID: <47250C8A.6020407@eecs.berkeley.edu>

Get the new functionality of part 2 in there first. Once you have the 
new phase 2 stuff then you can go back to multiple clients.
I will try to avoid testing the harder cases of multiple clients  & 
interleaved requests when testing phase 2 stuff.
Getting penalized twice for something is no fun :)

Daniel

ee122-dm at imail.eecs.berkeley.edu wrote:
> Hi, I was wondering how important it is to fix the errors (specifically
> the interleaved requests and buffer allocation errors) from part a. About
> how much of our grade will this be, since it would appear that part b
> doesn't rely on this feature any more than a did?
>
> Thanks,
> Aaron
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From ee122-dm at imail.EECS.Berkeley.EDU  Sun Oct 28 15:28:56 2007
From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU)
Date: Sun, 28 Oct 2007 15:28:56 -0700 (PDT)
Subject: [ee122] Fixing errors from part a
Message-ID: <60327.67.169.102.122.1193610536.squirrel@imail.eecs.berkeley.edu>

Sorry for posting this on newsgroup after emailing dank at eecs.. I had a
moment of weakness in which I thought the dank account might only be
checked around submission time. Here's Daniel's reply, if anyone else is
interested (and I'd like to think they are.)


Get the new functionality of part 2 in there first. Once you have the
new phase 2 stuff then you can go back to multiple clients.
I will try to avoid testing the harder cases of multiple clients when
testing phase 2 stuff.
Getting penalized twice for something is no fun :)

Daniel


From ee122-dm at imail.EECS.Berkeley.EDU  Sun Oct 28 15:39:54 2007
From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU)
Date: Sun, 28 Oct 2007 15:39:54 -0700 (PDT)
Subject: [ee122] Header format
Message-ID: <60472.67.169.102.122.1193611194.squirrel@imail.eecs.berkeley.edu>

What format do GET request headers have to follow? Are we implementing
these requirements? If we want to keep the connection alive, must there be
a line "\r\nConnection: Keep-Alive\r\n" in the request, or can it be more
lenient (i.e. spaces before, between, and after the words)

Thanks,
Aaron


From benjlau at berkeley.edu  Sun Oct 28 16:43:44 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Sun, 28 Oct 2007 16:43:44 -0700 (PDT)
Subject: [ee122]  bucket of questions
Message-ID: <1403.71.132.218.194.1193615024.squirrel@calmail.berkeley.edu>

let's say we're the client and the server sends us a bad response and we
decide to print an error message indicating that the response failed to
parse.  We just use Network Error I think?  Or is that only for atomic
network operations like socket() and connect()?  Does the answer also
apply to bogus status line and body (eg if chunked and rather than being
hex, we find alpha chars on the line for size).

Let's say you are blocked from writing to a file on the client side after
downloading from the server (maybe someone else is writing to it).  This
does not seem like a network error.  Can we just make up a new error for
cases which aren't network errors, so long as we're clear about it when
printing to stdout?

The project write up says that The HTTP response message and any
associated headers should be printed to standard output without any
additional processing.  Is this to be taken literally?  Just start
printing straight away?  Because the write up also says that If the
request does not succeed, your client should print the status code and
associated text, such as:
403 Forbidden: /secret/diary.html

But wouldn't this be redundant then, since we already printed out the HTTP
response message?  Also, when we print out the 403, should it be prefixed
by Network Error-- or does it not count as an error but as a valid message
that indicates a permissions denied on server side?

For the server during Phase 1, we printed the components of the request,
specifically the status line.  Are we only printing the headers now?  It
doesn't seem to say to print the status line anymore.

Back to the client, let us say that the server response has this:
Connection: aserawt8a

Is this an error or should we default to closing the connection?

In general, if we experience any kind of bad response parse, should we
just automatically close the connection even though we originally
stipulated a persistent connection, or should we keep it open?

What content type does a directory have?  I am thinking that we treat the
ls contents as just text/txt.

Thanks.


From dank at EECS.Berkeley.EDU  Sun Oct 28 17:01:39 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Sun, 28 Oct 2007 17:01:39 -0700
Subject: [ee122] bucket of questions
In-Reply-To: <1403.71.132.218.194.1193615024.squirrel@calmail.berkeley.edu>
References: <1403.71.132.218.194.1193615024.squirrel@calmail.berkeley.edu>
Message-ID: <f6705d303653.4724c073@EECS.Berkeley.EDU>



----- Original Message -----
From: benjlau at berkeley.edu
Date: Sunday, October 28, 2007 4:43 pm
Subject: [ee122]  bucket of questions

> let's say we're the client and the server sends us a bad response 
> and we
> decide to print an error message indicating that the response 
> failed to
> parse.  We just use Network Error I think?  Or is that only for atomic
> network operations like socket() and connect()?  Does the answer also
> apply to bogus status line and body (eg if chunked and rather than 
> beinghex, we find alpha chars on the line for size).
You can say
ERROR -- Parsing Error: <what the server sent you>

> 
> Let's say you are blocked from writing to a file on the client side 
> afterdownloading from the server (maybe someone else is writing to 
> it).  This
> does not seem like a network error.  Can we just make up a new 
> error for
> cases which aren't network errors, so long as we're clear about it 
> whenprinting to stdout?
> 
Yes, the important thing is to have the word 'error' somewhere in what you print to stdout.


> The project write up says that The HTTP response message and any
> associated headers should be printed to standard output without any
> additional processing.  Is this to be taken literally?  Just start
> printing straight away?  Because the write up also says that If the
> request does not succeed, your client should print the status code and
> associated text, such as:
> 403 Forbidden: /secret/diary.html
This was answered on the newsgroup already.
> 
> But wouldn't this be redundant then, since we already printed out 
> the HTTP
> response message?  Also, when we print out the 403, should it be 
> prefixedby Network Error-- or does it not count as an error but as 
> a valid message
> that indicates a permissions denied on server side?
> 
No, don't prefix it by anything. Just print out the line with 403 in it.

> For the server during Phase 1, we printed the components of the 
> request,specifically the status line.  Are we only printing the 
> headers now?  It
> doesn't seem to say to print the status line anymore.
> 
I will only be checking if you print the headers, not checking to see if you print the status line.

> Back to the client, let us say that the server response has this:
> Connection: aserawt8a
> 
It is an unrecognized header line, and it's not an error. Continue processing the request as per normal.

> Is this an error or should we default to closing the connection?
> 
> In general, if we experience any kind of bad response parse, should we
> just automatically close the connection even though we originally
> stipulated a persistent connection, or should we keep it open?

The client can close a persistent connection whenever it wants. So if the client gets a bad response from the server, then it should close the connection.

> 
> What content type does a directory have?  I am thinking that we 
> treat the
> ls contents as just text/txt.
A directory listing has content type text, like you guessed.

Daniel
> 
> Thanks.
> 
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> 

From benjlau at berkeley.edu  Sun Oct 28 18:45:45 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Sun, 28 Oct 2007 18:45:45 -0700 (PDT)
Subject: [ee122]  ending CRLF
Message-ID: <1840.71.132.218.194.1193622345.squirrel@calmail.berkeley.edu>

I noticed that the example on the project write up for chunking is

<512 bytes of data, plus an additional CRLF>
1b
<27 bytes of data, plus an additional CRLF>
0
<blank line here>

This is the grammar for chunking in the RFC and other pages:

       Chunked-Body   = *chunk
                        last-chunk
                        trailer
                        CRLF

       chunk          = chunk-size [ chunk-extension ] CRLF
                        chunk-data CRLF
       chunk-size     = 1*HEX
       last-chunk     = 1*("0") [ chunk-extension ] CRLF

So we are not only ignoring trailer and chunk-extension, we are also
ignoring the very last CRLF (in the chunked body) for thisproject?  If we
are not ignoring the last CRLF, shouldn't it be:

0
<blank line here>
<blank line here>




From huntingtonsurfca at gmail.com  Sun Oct 28 17:54:44 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Sun, 28 Oct 2007 17:54:44 -0700
Subject: [ee122] Can I access my server from a real browser?
Message-ID: <ffcc7690710281754j522d06a0kaefb716a5f5c2278@mail.gmail.com>

I want to know if I can use my IExplorer to access my webserver, and
how to do that since

http://star.cd.berkeley.edu:7788/

doesn't seem to work. I'm guessing permissions aren't allowed, but if
there's a place I can run my server and access it, that would be cool.

Rick

From fowler at eecs.berkeley.edu  Sun Oct 28 19:28:11 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Sun, 28 Oct 2007 19:28:11 -0700
Subject: [ee122] Can I access my server from a real browser?
In-Reply-To: <ffcc7690710281754j522d06a0kaefb716a5f5c2278@mail.gmail.com>
References: <ffcc7690710281754j522d06a0kaefb716a5f5c2278@mail.gmail.com>
Message-ID: <330471bf0710281928o21b7286fq533916cefed6f587@mail.gmail.com>

You can interact with your own local host by using your local host IP
address 127.0.0.1 ....

-Lisa

On 10/28/07, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> I want to know if I can use my IExplorer to access my webserver, and
> how to do that since
>
> http://star.cd.berkeley.edu:7788/
>
> doesn't seem to work. I'm guessing permissions aren't allowed, but if
> there's a place I can run my server and access it, that would be cool.
>
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From vern at cs.berkeley.edu  Sun Oct 28 19:55:26 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sun, 28 Oct 2007 19:55:26 -0700
Subject: [ee122] ending CRLF
In-Reply-To: <1840.71.132.218.194.1193622345.squirrel@calmail.berkeley.edu>
	(Sun, 28 Oct 2007 18:45:45 PDT).
Message-ID: <200710290255.l9T2tTVL011827@pork.ICSI.Berkeley.EDU>

> So we are not only ignoring trailer and chunk-extension, we are also
> ignoring the very last CRLF (in the chunked body) for thisproject?  If we
> are not ignoring the last CRLF, shouldn't it be:
> 
> 0
> <blank line here>
> <blank line here>

No, because there's already a CRLF after the 0.  That is, if we
wrote out the text fully, the example would be

	0<CRLF>
	<CRLF>

Visually, this is just one blank line, but it is two CRLF's.

		Vern

From simtan at berkeley.edu  Sun Oct 28 21:26:05 2007
From: simtan at berkeley.edu (Simon Tan)
Date: Sun, 28 Oct 2007 21:26:05 -0700
Subject: [ee122] bucket of questions
In-Reply-To: <f6705d303653.4724c073@EECS.Berkeley.EDU>
References: <1403.71.132.218.194.1193615024.squirrel@calmail.berkeley.edu>
	<f6705d303653.4724c073@EECS.Berkeley.EDU>
Message-ID: <op.t0xylrqo2hrgma@simthinkpad.gateway.2wire.net>

On Sun, 28 Oct 2007 17:01:39 -0700, Carrell Killebrew  
<dank at eecs.berkeley.edu> wrote:

>> In general, if we experience any kind of bad response parse, should we
>> just automatically close the connection even though we originally
>> stipulated a persistent connection, or should we keep it open?
> The client can close a persistent connection whenever it wants. So if  
> the client gets a bad response from the server, then it should close the  
> connection.

Does this count for 403, 404, 501, etc. errors? I.e. if a client gets  
anything *other than* a parsable 200 OK response, can it close its  
connection even though it is a persistent client?




-- 
~Simon Tan >> undergraduate at UC Berkeley
Source: simtan at berkeley.edu

From benjlau at berkeley.edu  Sun Oct 28 22:33:05 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Sun, 28 Oct 2007 22:33:05 -0700 (PDT)
Subject: [ee122]  unwanted persistence
Message-ID: <2618.71.132.218.194.1193635985.squirrel@calmail.berkeley.edu>

The client specifies a non persistent connection.  The server offers a
response back that includes a Keep-Alive and then either a chunking header
or a Content Length header.  What do you do?



From vern at cs.berkeley.edu  Sun Oct 28 22:41:07 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sun, 28 Oct 2007 22:41:07 -0700
Subject: [ee122] unwanted persistence
In-Reply-To: <2618.71.132.218.194.1193635985.squirrel@calmail.berkeley.edu>
	(Sun, 28 Oct 2007 22:33:05 PDT).
Message-ID: <200710290541.l9T5fBbU013778@pork.ICSI.Berkeley.EDU>

> The client specifies a non persistent connection.  The server offers a
> response back that includes a Keep-Alive

It doesn't matter what the server indicates regarding Keep-Alive, if the
client didn't offer it then the client needn't honor it.

> and then either a chunking header
> or a Content Length header.

Those are in principle separate.  If the server includes either, then that
had better be how it frames the item it returns.

		Vern

From vern at cs.berkeley.edu  Sun Oct 28 22:43:14 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Sun, 28 Oct 2007 22:43:14 -0700
Subject: [ee122] bucket of questions
In-Reply-To: <op.t0xylrqo2hrgma@simthinkpad.gateway.2wire.net> (Sun,
	28 Oct 2007 21:26:05 PDT).
Message-ID: <200710290543.l9T5hIZ7013805@pork.ICSI.Berkeley.EDU>

> > The client can close a persistent connection whenever it wants. So if  
> > the client gets a bad response from the server, then it should close the  
> > connection.
> 
> Does this count for 403, 404, 501, etc. errors? I.e. if a client gets  
> anything *other than* a parsable 200 OK response, can it close its  
> connection even though it is a persistent client?

It can close it even if it gets a 200 response (once it receives the item
that goes with the response).

Persistent connections are not a promise by the client to keep the connection
open; they're a promise by the server to accept multiple requests on the
connection if the client decides to send them.

		Vern

From jeremyfleischman at gmail.com  Mon Oct 29 06:13:04 2007
From: jeremyfleischman at gmail.com (Jeremy Fleischman)
Date: Mon, 29 Oct 2007 06:13:04 -0700
Subject: [ee122] Persistent Connections
Message-ID: <5830e3770710290613n64e056a4u3e96de5204fb77d1@mail.gmail.com>

Two quick questions.

Say that my client connects to a given server, say fourtytwo.com (after
typing in http://fourtytwo.com) and requests a persistent connection by
including the header "Connection: Keep-Alive". Say that the server decides
to honor the request. Now I type http://fourtytwo.com:7788 into my client.
Since I'm using persistent connections, the spec tells us to re-use the
existing connection to fourtytwo.com. However, this existing connection is
to port 80, not port 7788! Should we be checking the port number when
deciding whether to re-use a connection?

Also, why oh why does the spec not allow for horizontal dashes ( - ) in a
hostname? Lots of real domain names have them, and it's driven me crazy
trying to test my client out in the "real world", and finding that it can't
connect to these real websites.

Thanks!
Jeremy Fleischman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071029/5bfbb092/attachment.html 

From jeremyfleischman at berkeley.edu  Mon Oct 29 06:13:59 2007
From: jeremyfleischman at berkeley.edu (Jeremy Fleischman)
Date: Mon, 29 Oct 2007 06:13:59 -0700
Subject: [ee122] Persistent Connections
Message-ID: <5830e3770710290613iee613eam12d13f1449b60fb8@mail.gmail.com>

Two quick questions.

Say that my client connects to a given server, say fourtytwo.com (after
typing in http://fourtytwo.com) and requests a persistent connection by
including the header "Connection: Keep-Alive". Say that the server decides
to honor the request. Now I type http://fourtytwo.com:7788 into my client.
Since I'm using persistent connections, the spec tells us to re-use the
existing connection to fourtytwo.com . However, this existing connection is
to port 80, not port 7788! Should we be checking the port number when
deciding whether to re-use a connection?

Also, why oh why does the spec not allow for horizontal dashes ( - ) in a
hostname? Lots of real domain names have them, and it's driven me crazy
trying to test my client out in the "real world", and finding that it can't
connect to these real websites.

Thanks!Jeremy Fleischman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071029/e0e05542/attachment.html 

From fowler at eecs.berkeley.edu  Mon Oct 29 14:03:43 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 14:03:43 -0700
Subject: [ee122] Persistent Connections
In-Reply-To: <5830e3770710290613iee613eam12d13f1449b60fb8@mail.gmail.com>
References: <5830e3770710290613iee613eam12d13f1449b60fb8@mail.gmail.com>
Message-ID: <330471bf0710291403i4bbbd23ft8d9743aefa176cfa@mail.gmail.com>

On 10/29/07, Jeremy Fleischman <jeremyfleischman at berkeley.edu> wrote:
>
> Two quick questions.
>
> Say that my client connects to a given server, say fourtytwo.com (after
> typing in http://fourtytwo.com) and requests a persistent connection by
> including the header "Connection: Keep-Alive". Say that the server decides
> to honor the request. Now I type http://fourtytwo.com:7788 into my client.
> Since I'm using persistent connections, the spec tells us to re-use the
> existing connection to fourtytwo.com . However, this existing connection is
> to port 80, not port 7788! Should we be checking the port number when
> deciding whether to re-use a connection?

Yes you should.  The port # does matter.

> Also, why oh why does the spec not allow for horizontal dashes ( - ) in a
> hostname? Lots of real domain names have them, and it's driven me crazy
> trying to test my client out in the "real world", and finding that it can't
> connect to these real websites.

I'm sorry.  Unfortunately this is not an uncommon experience when
writing code.  You might find ways to make your client "better" but if
it goes against the specs, then it'll be "wrong", even if it is
"better".  Please try to use sites that don't have dashes in them.
You may extend your client with an option to support dashes, so long
as you return it to the spec-compliant form before you submit.

-Lisa

From newtonhang at berkeley.edu  Mon Oct 29 13:38:37 2007
From: newtonhang at berkeley.edu (Newton S. Hang)
Date: Mon, 29 Oct 2007 13:38:37 -0700 (PDT)
Subject: [ee122] file type handling
Message-ID: <61002.128.32.42.27.1193690317.squirrel@calmail.berkeley.edu>

How do we determine what is bad request?  Also, I was wondering how to
figure out the permission of a file.

- Newton


From huntingtonsurfca at gmail.com  Mon Oct 29 16:50:24 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Mon, 29 Oct 2007 16:50:24 -0700
Subject: [ee122] Can't find my traffic using wireshark
Message-ID: <ffcc7690710291650i7e42ae05r4bacb33659466750@mail.gmail.com>

I'm trying to watch the interactions of my server/client for the lab
and I can't find it.

I did catch the trace where it talked to the lab website (client to
website), but I can't find my traffic using http filter when using my
client to server to client only.

I was filtering for the port numbers that my server is running on (src
port 7788 or dst port 7788). I changed this to 80 and ran the settings
while accessing yahoo and it worked there, just not when I'm trying to
talk to my webserver.

Any ideas?

Rick

From fowler at eecs.berkeley.edu  Mon Oct 29 17:47:18 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 17:47:18 -0700
Subject: [ee122] Can't find my traffic using wireshark
In-Reply-To: <ffcc7690710291650i7e42ae05r4bacb33659466750@mail.gmail.com>
References: <ffcc7690710291650i7e42ae05r4bacb33659466750@mail.gmail.com>
Message-ID: <330471bf0710291747g6fb2342co9a427942291b077e@mail.gmail.com>

If you're your server is running on the same machine as the client,
try tracing the loopback adapter....

-Lisa

On 10/29/07, Richard Schmidt <huntingtonsurfca at gmail.com> wrote:
> I'm trying to watch the interactions of my server/client for the lab
> and I can't find it.
>
> I did catch the trace where it talked to the lab website (client to
> website), but I can't find my traffic using http filter when using my
> client to server to client only.
>
> I was filtering for the port numbers that my server is running on (src
> port 7788 or dst port 7788). I changed this to 80 and ran the settings
> while accessing yahoo and it worked there, just not when I'm trying to
> talk to my webserver.
>
> Any ideas?
>
> Rick
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From fowler at eecs.berkeley.edu  Mon Oct 29 17:48:14 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 17:48:14 -0700
Subject: [ee122] file type handling
In-Reply-To: <61002.128.32.42.27.1193690317.squirrel@calmail.berkeley.edu>
References: <61002.128.32.42.27.1193690317.squirrel@calmail.berkeley.edu>
Message-ID: <330471bf0710291748p776015berd498108df8fdb19c@mail.gmail.com>

Please read through the mailing list archives and let me know if you
still have questions.

Thanks!
Lisa

On 10/29/07, Newton S. Hang <newtonhang at berkeley.edu> wrote:
> How do we determine what is bad request?  Also, I was wondering how to
> figure out the permission of a file.
>
> - Newton
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From vern at cs.berkeley.edu  Mon Oct 29 18:33:09 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Mon, 29 Oct 2007 18:33:09 -0700
Subject: [ee122] Can't find my traffic using wireshark
In-Reply-To: <330471bf0710291747g6fb2342co9a427942291b077e@mail.gmail.com>
	(Mon, 29 Oct 2007 17:47:18 PDT).
Message-ID: <200710300133.l9U1XDTL003490@pork.ICSI.Berkeley.EDU>

> If you're your server is running on the same machine as the client,
> try tracing the loopback adapter....

(which you do using -i lo0 on most systems)

From ee122-dm at imail.EECS.Berkeley.EDU  Mon Oct 29 19:38:46 2007
From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU)
Date: Mon, 29 Oct 2007 19:38:46 -0700 (PDT)
Subject: [ee122] Server Printing to stdout
Message-ID: <63807.67.169.102.122.1193711926.squirrel@imail.eecs.berkeley.edu>

Exactly what does the server print to stdout? The error message, if
applicable? The entire HTTP response? The response minus the body? The
spec says we shouldn't print the parts of the GET request, but that's all
it says on the subject.

Aaron


From fowler at eecs.berkeley.edu  Mon Oct 29 19:42:57 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 19:42:57 -0700
Subject: [ee122] Server Printing to stdout
In-Reply-To: <63807.67.169.102.122.1193711926.squirrel@imail.eecs.berkeley.edu>
References: <63807.67.169.102.122.1193711926.squirrel@imail.eecs.berkeley.edu>
Message-ID: <330471bf0710291942p3e22fe36q46e67ef84ced1a06@mail.gmail.com>

On 10/29/07, ee122-dm at imail.eecs.berkeley.edu
<ee122-dm at imail.eecs.berkeley.edu> wrote:
> Exactly what does the server print to stdout? The error message, if
> applicable? The entire HTTP response? The response minus the body? The
> spec says we shouldn't print the parts of the GET request, but that's all
> it says on the subject.
>
> Aaron
>


I actually answered this one a few times to individuals, so here's my
response, now on the list! :)

---------- Forwarded message ----------
From: Lisa Fowler <fowler at eecs.berkeley.edu>
Date: Oct 26, 2007 8:07 AM
Subject: Re: question about server standard output


Another student had the same question.  It's a good one.  I told the
other student that for your debugging purposes, you might as well have
some debugging output on your server, but make it all controlled by a
"VERBOSE" constant or something like that.  Then disable it for your
final submit, and say in your readme that "in order to conserve server
resources, my server handles requests silently."

From benjlau at berkeley.edu  Mon Oct 29 20:07:24 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Mon, 29 Oct 2007 20:07:24 -0700 (PDT)
Subject: [ee122]  spurious
Message-ID: <2477.71.132.199.215.1193713644.squirrel@calmail.berkeley.edu>

What happened to the spurious text before CRLF message from Phase 1? 
Someone earlier, I think it was Ben Wang, asked about this but there was
no response and I can't find any info relating to its disappearance on the
mailing list.  Has it just been integrated into the Invalid HTTP Version
message?  Or do we just simply completely ignore spurious text now?  Sorry
if this was mentioned but I cannot find it and since the earlier question
was not answered I wonder if it was just forgotten.


From fowler at eecs.berkeley.edu  Mon Oct 29 20:27:04 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 20:27:04 -0700
Subject: [ee122] spurious
In-Reply-To: <2477.71.132.199.215.1193713644.squirrel@calmail.berkeley.edu>
References: <2477.71.132.199.215.1193713644.squirrel@calmail.berkeley.edu>
Message-ID: <330471bf0710292027u52d8054ao4db6c6c55d4f9c54@mail.gmail.com>

Treat all (appropriate) errors from Milestone A, such as this one, as
400 Bad Request errors.

-Lisa

On 10/29/07, benjlau at berkeley.edu <benjlau at berkeley.edu> wrote:
> What happened to the spurious text before CRLF message from Phase 1?
> Someone earlier, I think it was Ben Wang, asked about this but there was
> no response and I can't find any info relating to its disappearance on the
> mailing list.  Has it just been integrated into the Invalid HTTP Version
> message?  Or do we just simply completely ignore spurious text now?  Sorry
> if this was mentioned but I cannot find it and since the earlier question
> was not answered I wonder if it was just forgotten.
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From fowler at eecs.berkeley.edu  Mon Oct 29 20:29:43 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 20:29:43 -0700
Subject: [ee122] spurious
In-Reply-To: <330471bf0710292027u52d8054ao4db6c6c55d4f9c54@mail.gmail.com>
References: <2477.71.132.199.215.1193713644.squirrel@calmail.berkeley.edu>
	<330471bf0710292027u52d8054ao4db6c6c55d4f9c54@mail.gmail.com>
Message-ID: <330471bf0710292029x59d8ef4by967c30f990232eaf@mail.gmail.com>

Ah, sorry.  Daniel needs to answer this one.  I see your question is
if there should be a "HTTP/1.0 400 Bad Request: ERROR -- Invalid
characters following the protocol string" returned from the server in
the case of spurious tokens after the method token.

Daniel's say is the final say on that.  Daniel?

-Lisa

On 10/29/07, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:
> Treat all (appropriate) errors from Milestone A, such as this one, as
> 400 Bad Request errors.
>
> -Lisa
>
> On 10/29/07, benjlau at berkeley.edu <benjlau at berkeley.edu> wrote:
> > What happened to the spurious text before CRLF message from Phase 1?
> > Someone earlier, I think it was Ben Wang, asked about this but there was
> > no response and I can't find any info relating to its disappearance on the
> > mailing list.  Has it just been integrated into the Invalid HTTP Version
> > message?  Or do we just simply completely ignore spurious text now?  Sorry
> > if this was mentioned but I cannot find it and since the earlier question
> > was not answered I wonder if it was just forgotten.
> >
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
>

From benjlau at berkeley.edu  Mon Oct 29 20:40:13 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Mon, 29 Oct 2007 20:40:13 -0700 (PDT)
Subject: [ee122]  incommunicable vs network
Message-ID: <2598.71.132.199.215.1193715613.squirrel@calmail.berkeley.edu>

It's hard to tell which of server side errors to label incommunicable or
network.  In the last project it was clear, anything related to the
network was just going to be network error but this time we have
incommunicable errors that encompass any errors that cannot be
communicated to the client (i.e. socket failures or a bad port number). 
Socket failures and bad ports seem to cover almost all errors.  Can
someone give me examples of errors that directly fall into each category,
and maybe a better rule of thumb to apply?  Right now I have it pegged
kind of like this but it's all the same to me really (thats why it's
mostly incommunicable messages)

bad command line args-- incommunicable because we will never start program
socket(), bind(), accept(), listen(), send(), select() -- incommunicable
because we cannot communicate with one or more clients and/or we terminate
the program (liek for select)
close()-- network because it does not necessarily stop us from
communicating.  Always recoverable I think.
error when setting the original server socket reusable-- incommunicable
because we will not continue the program (at least that's the way I
implemented it).
couldn't parse get request headers-- network because we send a 400 to the
client



From vern at cs.berkeley.edu  Mon Oct 29 21:51:29 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Mon, 29 Oct 2007 21:51:29 -0700
Subject: [ee122] Persistent Connections
In-Reply-To: <330471bf0710291403i4bbbd23ft8d9743aefa176cfa@mail.gmail.com>
	(Mon, 29 Oct 2007 14:03:43 PDT).
Message-ID: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>

> You might find ways to make your client "better" but if
> it goes against the specs, then it'll be "wrong", even if it is
> "better".

I didn't discuss this in lecture, but specs are often written with language
indicating which elements are strictly required; required as a minimum;
prohibited; or such.  Allowing for '-', if documented as an extension,
strikes me as reasonable (where the spec describing hostnames is of the
"required as a minimum form").  I don't see how this would complicate
testing of the implementation.  That said, Daniel should have the final
word on whether such an addition will mess things up, as he's the one who
has to correctly automate the grading of all 75+ projects.

		Vern

From merry_c at berkeley.edu  Mon Oct 29 22:17:12 2007
From: merry_c at berkeley.edu (Merry Choi)
Date: Mon, 29 Oct 2007 22:17:12 -0700
Subject: [ee122] resolving filesnames and directories
In-Reply-To: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>
Message-ID: <E1ImjTQ-0005YC-4a@fe1.calmail>

Just wanted to make sure I'm interpreting these steps correctly.

If the file requested does not have an extension you can assume it is a
request for a directory. You first append /index.html to see if that
directory has an index.html file. If yes, then you send the index.html file.
If not, then you perform and ls and send the directory contents. Yes?
(Please be yes. :)




From fowler at eecs.berkeley.edu  Mon Oct 29 22:33:07 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 22:33:07 -0700
Subject: [ee122] resolving filesnames and directories
In-Reply-To: <E1ImjTQ-0005YC-4a@fe1.calmail>
References: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>
	<E1ImjTQ-0005YC-4a@fe1.calmail>
Message-ID: <330471bf0710292233r1f45d453rcd9fec90d6c12529@mail.gmail.com>

Close, but you're missing the first step....

e.g. request is for "http://www.domain.com/foo"

Assume is not a directory.  Test for file "foo":
  + File "foo" exists.  Return foo or permission denied.
  + File "foo" does not exist.  Return does not exist.
  + File "foo" is not a file, but is a directory.

Then, if directory, continue as you described.

I hope that helps!

Lisa

On 10/29/07, Merry Choi <merry_c at berkeley.edu> wrote:
> Just wanted to make sure I'm interpreting these steps correctly.
>
> If the file requested does not have an extension you can assume it is a
> request for a directory. You first append /index.html to see if that
> directory has an index.html file. If yes, then you send the index.html file.
> If not, then you perform and ls and send the directory contents. Yes?
> (Please be yes. :)
>
>
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>

From fowler at eecs.berkeley.edu  Mon Oct 29 22:35:11 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 22:35:11 -0700
Subject: [ee122] resolving filesnames and directories
In-Reply-To: <330471bf0710292233r1f45d453rcd9fec90d6c12529@mail.gmail.com>
References: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>
	<E1ImjTQ-0005YC-4a@fe1.calmail>
	<330471bf0710292233r1f45d453rcd9fec90d6c12529@mail.gmail.com>
Message-ID: <330471bf0710292235v40e0130aibdee51418379ca8f@mail.gmail.com>

Actually, you'd never return "foo" if foo doesn't have an extension,
per the spec.  So the "return foo" below should be replaced with the
appropriate not-supported error.

-Lisa

On 10/29/07, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:
> Close, but you're missing the first step....
>
> e.g. request is for "http://www.domain.com/foo"
>
> Assume is not a directory.  Test for file "foo":
>   + File "foo" exists.  Return foo or permission denied.
>   + File "foo" does not exist.  Return does not exist.
>   + File "foo" is not a file, but is a directory.
>
> Then, if directory, continue as you described.
>
> I hope that helps!
>
> Lisa
>
> On 10/29/07, Merry Choi <merry_c at berkeley.edu> wrote:
> > Just wanted to make sure I'm interpreting these steps correctly.
> >
> > If the file requested does not have an extension you can assume it is a
> > request for a directory. You first append /index.html to see if that
> > directory has an index.html file. If yes, then you send the index.html file.
> > If not, then you perform and ls and send the directory contents. Yes?
> > (Please be yes. :)
> >
> >
> >
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
>

From merry_c at berkeley.edu  Mon Oct 29 23:45:23 2007
From: merry_c at berkeley.edu (Merry Choi)
Date: Mon, 29 Oct 2007 23:45:23 -0700
Subject: [ee122] resolving filesnames and directories
In-Reply-To: <330471bf0710292235v40e0130aibdee51418379ca8f@mail.gmail.com>
Message-ID: <E1Imkql-00037Q-3a@fe1.calmail>

So essentially, if the URI does not have a slash after it, nor a
.txt/.gif/.html/.jpg ... then we can return 501?




-----Original Message-----
From: lisa.fowler at gmail.com [mailto:lisa.fowler at gmail.com] On Behalf Of Lisa
Fowler
Sent: Monday, October 29, 2007 10:35 PM
To: Merry Choi
Cc: ee122 at icsi.berkeley.edu
Subject: Re: [ee122] resolving filesnames and directories

Actually, you'd never return "foo" if foo doesn't have an extension,
per the spec.  So the "return foo" below should be replaced with the
appropriate not-supported error.

-Lisa

On 10/29/07, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:
> Close, but you're missing the first step....
>
> e.g. request is for "http://www.domain.com/foo"
>
> Assume is not a directory.  Test for file "foo":
>   + File "foo" exists.  Return foo or permission denied.
>   + File "foo" does not exist.  Return does not exist.
>   + File "foo" is not a file, but is a directory.
>
> Then, if directory, continue as you described.
>
> I hope that helps!
>
> Lisa
>
> On 10/29/07, Merry Choi <merry_c at berkeley.edu> wrote:
> > Just wanted to make sure I'm interpreting these steps correctly.
> >
> > If the file requested does not have an extension you can assume it is a
> > request for a directory. You first append /index.html to see if that
> > directory has an index.html file. If yes, then you send the index.html
file.
> > If not, then you perform and ls and send the directory contents. Yes?
> > (Please be yes. :)
> >
> >
> >
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
>


From fowler at eecs.berkeley.edu  Mon Oct 29 23:48:24 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Mon, 29 Oct 2007 23:48:24 -0700
Subject: [ee122] resolving filesnames and directories
In-Reply-To: <E1Imkql-00037Q-3a@fe1.calmail>
References: <330471bf0710292235v40e0130aibdee51418379ca8f@mail.gmail.com>
	<E1Imkql-00037Q-3a@fe1.calmail>
Message-ID: <330471bf0710292348n3a643b14n700c62a04b3e8c49@mail.gmail.com>

Not quite.... if "foo" is a directory, you have to handle it
appropriately, even if it doesn't have a slash after it.

-Lisa

On 10/29/07, Merry Choi <merry_c at berkeley.edu> wrote:
> So essentially, if the URI does not have a slash after it, nor a
> .txt/.gif/.html/.jpg ... then we can return 501?
>
>
>
>
> -----Original Message-----
> From: lisa.fowler at gmail.com [mailto:lisa.fowler at gmail.com] On Behalf Of Lisa
> Fowler
> Sent: Monday, October 29, 2007 10:35 PM
> To: Merry Choi
> Cc: ee122 at icsi.berkeley.edu
> Subject: Re: [ee122] resolving filesnames and directories
>
> Actually, you'd never return "foo" if foo doesn't have an extension,
> per the spec.  So the "return foo" below should be replaced with the
> appropriate not-supported error.
>
> -Lisa
>
> On 10/29/07, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:
> > Close, but you're missing the first step....
> >
> > e.g. request is for "http://www.domain.com/foo"
> >
> > Assume is not a directory.  Test for file "foo":
> >   + File "foo" exists.  Return foo or permission denied.
> >   + File "foo" does not exist.  Return does not exist.
> >   + File "foo" is not a file, but is a directory.
> >
> > Then, if directory, continue as you described.
> >
> > I hope that helps!
> >
> > Lisa
> >
> > On 10/29/07, Merry Choi <merry_c at berkeley.edu> wrote:
> > > Just wanted to make sure I'm interpreting these steps correctly.
> > >
> > > If the file requested does not have an extension you can assume it is a
> > > request for a directory. You first append /index.html to see if that
> > > directory has an index.html file. If yes, then you send the index.html
> file.
> > > If not, then you perform and ls and send the directory contents. Yes?
> > > (Please be yes. :)
> > >
> > >
> > >
> > > _______________________________________________
> > > ee122 mailing list
> > > ee122 at mailman.ICSI.Berkeley.EDU
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> > >
> >
>
>

From dank at EECS.Berkeley.EDU  Tue Oct 30 02:36:53 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Tue, 30 Oct 2007 02:36:53 -0700
Subject: [ee122] spurious
In-Reply-To: <330471bf0710292029x59d8ef4by967c30f990232eaf@mail.gmail.com>
References: <2477.71.132.199.215.1193713644.squirrel@calmail.berkeley.edu>
	<330471bf0710292027u52d8054ao4db6c6c55d4f9c54@mail.gmail.com>
	<330471bf0710292029x59d8ef4by967c30f990232eaf@mail.gmail.com>
Message-ID: <f66361457ab7.472698c5@EECS.Berkeley.EDU>

Go with a 400 Bad Request
something like what Lisa said:
HTTP/1.0 400 Bad Request: ERROR -- Invalid characters following the protocol string


Daniel


----- Original Message -----
From: Lisa Fowler <fowler at EECS.Berkeley.EDU>
Date: Monday, October 29, 2007 8:29 pm
Subject: Re: [ee122] spurious

> Ah, sorry.  Daniel needs to answer this one.  I see your question is
> if there should be a "HTTP/1.0 400 Bad Request: ERROR -- Invalid
> characters following the protocol string" returned from the server in
> the case of spurious tokens after the method token.
> 
> Daniel's say is the final say on that.  Daniel?
> 
> -Lisa
> 
> On 10/29/07, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:
> > Treat all (appropriate) errors from Milestone A, such as this 
> one, as
> > 400 Bad Request errors.
> >
> > -Lisa
> >
> > On 10/29/07, benjlau at berkeley.edu <benjlau at berkeley.edu> wrote:
> > > What happened to the spurious text before CRLF message from 
> Phase 1?
> > > Someone earlier, I think it was Ben Wang, asked about this but 
> there was
> > > no response and I can't find any info relating to its 
> disappearance on the
> > > mailing list.  Has it just been integrated into the Invalid 
> HTTP Version
> > > message?  Or do we just simply completely ignore spurious text 
> now?  Sorry
> > > if this was mentioned but I cannot find it and since the 
> earlier question
> > > was not answered I wonder if it was just forgotten.
> > >
> > > _______________________________________________
> > > ee122 mailing list
> > > ee122 at mailman.ICSI.Berkeley.EDU
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> > >
> >
> 

From dank at EECS.Berkeley.EDU  Tue Oct 30 03:05:36 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Tue, 30 Oct 2007 03:05:36 -0700
Subject: [ee122] incommunicable vs network
In-Reply-To: <2598.71.132.199.215.1193715613.squirrel@calmail.berkeley.edu>
References: <2598.71.132.199.215.1193715613.squirrel@calmail.berkeley.edu>
Message-ID: <f68077ff3109.47269f80@EECS.Berkeley.EDU>

I think this might be a helpful rule of thumb:

If you're connected to a client and something happens (that this client would care about, not something happening to another client), and you can't tell the client, it's incommunicable error. For example if you are sending a file to a client, and in the middle of the transfer, the filehandle you're reading from goes bad, there's not way to really tell the client what happened because you're in the middle of the transfer. So that would be incommunicable.

If you can't parse their request, you reply with the appropriate HTTP response error message, but it's not a network error.

Network errors are usually when a networking call fails for some reason. so socket() bind() etc. are network errors.

Bad command line args are neither type of error. It's not incommunicable because no clients are connected to you yet, so there's nothing to tell them anyway.

Just do your best. Honestly as long as your error message has the word 'error' in it, that's probably all that I will be looking for in some cases...

Daniel


----- Original Message -----
From: benjlau at berkeley.edu
Date: Monday, October 29, 2007 8:40 pm
Subject: [ee122]  incommunicable vs network

> It's hard to tell which of server side errors to label 
> incommunicable or
> network.  In the last project it was clear, anything related to the
> network was just going to be network error but this time we have
> incommunicable errors that encompass any errors that cannot be
> communicated to the client (i.e. socket failures or a bad port 
> number). 
> Socket failures and bad ports seem to cover almost all errors.  Can
> someone give me examples of errors that directly fall into each 
> category,and maybe a better rule of thumb to apply?  Right now I 
> have it pegged
> kind of like this but it's all the same to me really (thats why it's
> mostly incommunicable messages)
> 
> bad command line args-- incommunicable because we will never start 
> programsocket(), bind(), accept(), listen(), send(), select() -- 
> incommunicablebecause we cannot communicate with one or more 
> clients and/or we terminate
> the program (liek for select)
> close()-- network because it does not necessarily stop us from
> communicating.  Always recoverable I think.
> error when setting the original server socket reusable-- 
> incommunicablebecause we will not continue the program (at least 
> that's the way I
> implemented it).
> couldn't parse get request headers-- network because we send a 400 
> to the
> client
> 
> 
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> 

From dank at eecs.berkeley.edu  Tue Oct 30 04:09:34 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Tue, 30 Oct 2007 04:09:34 -0700
Subject: [ee122] Header format
In-Reply-To: <60472.67.169.102.122.1193611194.squirrel@imail.eecs.berkeley.edu>
References: <60472.67.169.102.122.1193611194.squirrel@imail.eecs.berkeley.edu>
Message-ID: <472710EE.4020002@eecs.berkeley.edu>

You may be more lenient in what you look for, but you should transmit it 
exactly as it appears in the RFC (which is what you put in your email).

Daniel

ee122-dm at imail.eecs.berkeley.edu wrote:
> What format do GET request headers have to follow? Are we implementing
> these requirements? If we want to keep the connection alive, must there be
> a line "\r\nConnection: Keep-Alive\r\n" in the request, or can it be more
> lenient (i.e. spaces before, between, and after the words)
>
> Thanks,
> Aaron
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From simtan at berkeley.edu  Tue Oct 30 04:13:45 2007
From: simtan at berkeley.edu (Simon Tan)
Date: Tue, 30 Oct 2007 04:13:45 -0700
Subject: [ee122] Server Printing to stdout
In-Reply-To: <330471bf0710291942p3e22fe36q46e67ef84ced1a06@mail.gmail.com>
References: <63807.67.169.102.122.1193711926.squirrel@imail.eecs.berkeley.edu>
	<330471bf0710291942p3e22fe36q46e67ef84ced1a06@mail.gmail.com>
Message-ID: <op.t00b47zc2hrgma@simthinkpad.gateway.2wire.net>

I think the spec still states, between pages 6 and 7, that...

The server prints to standard out:
GET /index.html HTTP/1.0
Connection: Keep-Alive
<a blank line here>

Basically, it looks like it prints the GET request and headers.


On Mon, 29 Oct 2007 19:42:57 -0700, Lisa Fowler <fowler at eecs.berkeley.edu>  
wrote:

> my server handles requests silently.



-- 
~Simon Tan >> undergraduate at UC Berkeley
Source: simtan at berkeley.edu
It's more like the Tan BAM!

From dank at eecs.berkeley.edu  Tue Oct 30 04:17:19 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Tue, 30 Oct 2007 04:17:19 -0700
Subject: [ee122] Server Printing to stdout
In-Reply-To: <op.t00b47zc2hrgma@simthinkpad.gateway.2wire.net>
References: <63807.67.169.102.122.1193711926.squirrel@imail.eecs.berkeley.edu>
	<330471bf0710291942p3e22fe36q46e67ef84ced1a06@mail.gmail.com>
	<op.t00b47zc2hrgma@simthinkpad.gateway.2wire.net>
Message-ID: <472712BF.9090309@eecs.berkeley.edu>

Just confirming what Simon said.

Daniel

Simon Tan wrote:
> I think the spec still states, between pages 6 and 7, that...
>
> The server prints to standard out:
> GET /index.html HTTP/1.0
> Connection: Keep-Alive
> <a blank line here>
>
> Basically, it looks like it prints the GET request and headers.
>
>   
>

From dank at eecs.berkeley.edu  Tue Oct 30 04:20:05 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Tue, 30 Oct 2007 04:20:05 -0700
Subject: [ee122] Persistent Connections
In-Reply-To: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>
References: <200710300451.l9U4pXHG006111@pork.ICSI.Berkeley.EDU>
Message-ID: <47271365.5000006@eecs.berkeley.edu>

As far as this particular case of having dashes in a hostname, I won't 
be testing to see if your client reports that as an invalid hostname, so 
go ahead and support it if you want to.

Of course in general, guessing how I'm going to autograde your projects 
is a risky business :)

Daniel

vern at EECS.Berkeley.EDU wrote:
>> You might find ways to make your client "better" but if
>> it goes against the specs, then it'll be "wrong", even if it is
>> "better".
>>     
>
> I didn't discuss this in lecture, but specs are often written with language
> indicating which elements are strictly required; required as a minimum;
> prohibited; or such.  Allowing for '-', if documented as an extension,
> strikes me as reasonable (where the spec describing hostnames is of the
> "required as a minimum form").  I don't see how this would complicate
> testing of the implementation.  That said, Daniel should have the final
> word on whether such an addition will mess things up, as he's the one who
> has to correctly automate the grading of all 75+ projects.
>
> 		Vern
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From kennyc2k2 at hotmail.com  Mon Oct 29 23:17:27 2007
From: kennyc2k2 at hotmail.com (Kenny Chan)
Date: Mon, 29 Oct 2007 23:17:27 -0700
Subject: [ee122]  resolving filesnames and directories
Message-ID: <BAY104-W120FD309EFA7E2EF58C408B0920@phx.gbl>


Quick question:



What is the "precedence" of the status codes?

For example if I have a request URI: /xxx.avi



Assuming xxx.avi does not exist in the directory,

should I say 404 Not found, or 501 Not implemented?



Thanks



-kenny




_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071029/6ce74d68/attachment.html 

From huntingtonsurfca at gmail.com  Tue Oct 30 01:06:26 2007
From: huntingtonsurfca at gmail.com (Richard Schmidt)
Date: Tue, 30 Oct 2007 01:06:26 -0700
Subject: [ee122] Can't find my traffic using wireshark
In-Reply-To: <200710300540.l9U5enR4006712@pork.ICSI.Berkeley.EDU>
References: <ffcc7690710292231p2b65da21n96a43cf3d786731a@mail.gmail.com>
	<200710300540.l9U5enR4006712@pork.ICSI.Berkeley.EDU>
Message-ID: <ffcc7690710300106q49e2e9bbj4afa59d4bb7f16b7@mail.gmail.com>

Ok so for everyone who will inevitably want to do know:

You have to recompile your server on ilinux3. But ilinux3 doesn't
recognize -lsocket so your usual makefile won't work. However, you can
just compile using

>gcc -c yourfile.c

then

> gcc yourfile.o -o http_server [No need to link -lsocket or -lnsl...]

And the server will run fine (go figure...).

Also cool, when running your server on ilinux3 you can (if you've done
the project correctly) access your webServer from a normal web
browser!

Just click on the link you've typed into the client and a browser
should pop up displaying the same stuff. It'll take the same arguments
you provide into the address bar as the http_client, and will display
text, etc.

Rick


On 10/29/07, vern at cs.berkeley.edu <vern at cs.berkeley.edu> wrote:
> > star [61] ~/proj1b > /share/b/ee122/tcpdump -s 0 -i lo0 -w file.trace
> > tcpdump.sun4u: lo0: No DLPI device found
> >
> > ----------
> > I tried this with other numbers and still the same error.
>
> Hmmmm, I don't know how to get this to work on Solaris :-(.
>
> Can you run the client and server on separate machines?  I believe
> ilinux3.eecs didn't firewall off user servers from the net.
>
>                Vern
>

From ofer at berkeley.edu  Tue Oct 30 12:49:06 2007
From: ofer at berkeley.edu (Ofer Sadgat)
Date: Tue, 30 Oct 2007 12:49:06 -0700
Subject: [ee122] Note
Message-ID: <000901c81b2d$f1893b00$d49bb100$@edu>

If you change the Http Version from 1.0 to 1.1 a chunked transfer encoding
(on the server side) should work. Right?

 

-Ofer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071030/0fd62ebf/attachment.html 

From miken087 at berkeley.edu  Tue Oct 30 14:50:28 2007
From: miken087 at berkeley.edu (miken087 at berkeley.edu)
Date: Tue, 30 Oct 2007 14:50:28 -0700 (PDT)
Subject: [ee122] (no subject)
Message-ID: <61224.67.169.102.122.1193781028.squirrel@calmail.berkeley.edu>

For the parsing of the "Connection: Keep-Alive" and "Transfer-Encoding:
chunked" headers, does the casing matter? Also does the number of spaces
between each word matter? For example would "connection:    Keep-aLive" be
valid? Thanks.

Michael Ngo




From a_kilman at berkeley.edu  Tue Oct 30 15:34:04 2007
From: a_kilman at berkeley.edu (Anthony Kilman)
Date: Tue, 30 Oct 2007 15:34:04 -0700
Subject: [ee122] Issues with c199
Message-ID: <1193783644.8150.11.camel@zerocool>

Hello.. I have my project ready to go. I finished the labs and
everything. I did most of the testing on ilinux3.eecs.berkeley.edu and
on my box at home.

Thought I'd give it a run on c199.eecs.berkeley.edu, but it was a no go.
I used the same make file in the reference code, and did a clean make.
It compiles, starts running, but just sits there. I got on gdb to see
the exact call that it hangs on.. select.

I've tried several combinations of client/server types. My box at home,
to ilinux3, that worked fine. Other way around.. works fine. Using
myhostname.local client/server both running on my machine, fine.. c199
is just being really stubborn.

And, on top of that, I thought I'd try the other way around. Run the
server on ilinux, and the client on c199. Just be thorough. Using the
same make file as the reference code, it doesn't get past the linking
stage. Here's what I get:

c199 [67] ~/proj1b/client > make
g++ -ggdb -Wall-lsocket -lnsl -o http_client http_client.cpp
Undefined                       first referenced
 symbol                             in file
recv                                /var/tmp//cctgg1cH.o
send                                /var/tmp//cctgg1cH.o
__xnet_connect                      /var/tmp//cctgg1cH.o
__xnet_socket                       /var/tmp//cctgg1cH.o
ld: fatal: Symbol referencing errors. No output written to http_client
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `http_client'

I should have all the correct headers, as how they are the same ones in
the ref code as well.

So, yeah. Any ideas? Also, why is c199 such a pain in the arse?

Thanks!

Anthony


From vern at cs.berkeley.edu  Tue Oct 30 15:55:55 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Tue, 30 Oct 2007 15:55:55 -0700
Subject: [ee122] Issues with c199
In-Reply-To: <1193783644.8150.11.camel@zerocool> (Tue,
	30 Oct 2007 15:34:04 PDT).
Message-ID: <200710302255.l9UMtx5e026155@pork.ICSI.Berkeley.EDU>

> Thought I'd give it a run on c199.eecs.berkeley.edu, but it was a no go.
> I used the same make file in the reference code, and did a clean make.
> It compiles, starts running, but just sits there. I got on gdb to see
> the exact call that it hangs on.. select.

I believe c199 has a firewall that disallows external connections to
any non-standard servers running on it :-(.

> c199 [67] ~/proj1b/client > make
> g++ -ggdb -Wall-lsocket -lnsl -o http_client http_client.cpp

If that's a verbatim report of the compile line, then best guess is that
the problem is "-Wall-lsocket", which needs to instead be "-Wall -lsocket"
(a blank between the two flags).

		Vern

From benjlau at berkeley.edu  Tue Oct 30 17:05:42 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Tue, 30 Oct 2007 17:05:42 -0700 (PDT)
Subject: [ee122]  untimely terminations
Message-ID: <1590.71.132.220.30.1193789142.squirrel@calmail.berkeley.edu>

Let's say the client is connected to the server in a persistent
connection.  They do the usual exchange of GET and response.  After some
period of inactivity, the server goes down.  The user types in a URL
equivalent to initiating the connection that was already set up (but is
now secretly broken due to server collapse).  Does it matter whether the
client assumes the connection is still there, tries sending, and then
fails and recovers, re-entering the loop and going back to the initial
state of the program (and expecting a new URL), or do we always have to
check to ensure the server hasn't died when we send a message in a
persistent connection.  If the latter, how can we do this?

Another scenario.  Let's say the client requests a persistent connection. 
The server obliges and chooses to chunk the response.  The client receives
some data and then waits for the last chunk.  While the client is waiting
for it, the server suddenly closes the connection.  What error message if
any should be shown on the client side?  I have this pegged as a parsing
error.  It's printed out.  Is that okay or is silently failing and
recovering back to the original state of the program better?

If the server declares a 403 or other 4-- error, and the client gets it,
and there was a persistent connection, should either or both close the
connection automatically?




From jkwang at berkeley.edu  Tue Oct 30 21:19:11 2007
From: jkwang at berkeley.edu (Jeff Wang)
Date: Tue, 30 Oct 2007 21:19:11 -0700
Subject: [ee122]  Persistent Connection Hanging
Message-ID: <619E0ECD-8050-4302-9366-F192526DC14D@berkeley.edu>

When I use Safari, with the keep-alive header, to request a file that  
doesn't exist (ie. "/asdfsaf"),
the browser just hangs and keeps on loading.

My server sends a 404 header, but no body.

Apparently, Safari is waiting for more data, but never gets it.


Is this correct?

From vern at cs.berkeley.edu  Tue Oct 30 21:27:01 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Tue, 30 Oct 2007 21:27:01 -0700
Subject: [ee122] Persistent Connection Hanging
In-Reply-To: <619E0ECD-8050-4302-9366-F192526DC14D@berkeley.edu> (Tue,
	30 Oct 2007 21:19:11 PDT).
Message-ID: <200710310427.l9V4R5RO030614@pork.ICSI.Berkeley.EDU>

> When I use Safari, with the keep-alive header, to request a file that  
> doesn't exist (ie. "/asdfsaf"),
> the browser just hangs and keeps on loading.
> 
> My server sends a 404 header, but no body.
> 
> Apparently, Safari is waiting for more data, but never gets it.

RFC 2616 states that a server SHOULD include an entity explaining the
problem when returning a 40x status code.  Apparently Safari requires this
(even though given the SHOULD it should be prepared to deal with its
absence).

		Vern

From drewlustro at gmail.com  Tue Oct 30 22:17:07 2007
From: drewlustro at gmail.com (Drew Lustro)
Date: Tue, 30 Oct 2007 22:17:07 -0700
Subject: [ee122] File w/o extension + Directory listing question...
Message-ID: <AD725EF2-6B86-41B9-89BB-FE0910D8B7C3@gmail.com>

So for directory listing, say the client requests "/foo"

If file "foo" exists, does that mean _no_matter_what_ we always just  
go "501 Not Implemented: /foo" because supported filetypes are  
determined by filename extension?

If "foo" is a directory, we're supposed to return the contents of the  
ls command. The documentation _suggests_ we pipe the results of ls  
into a file. Does this file need to be called something particular?  
Could we just call it .tmp_file_contents.txt and then return that (ie:  
end up doing HTTP/1.0 200 OK\nContent-Type: text/plain\nContent- 
Length: 9999\n\r\nCONTENTS-OF-.tmp_file_contents.txt) and then delete  
the temporary file?

Thanks

Drew

From ccowart at berkeley.edu  Tue Oct 30 23:39:51 2007
From: ccowart at berkeley.edu (Christopher Cowart)
Date: Tue, 30 Oct 2007 23:39:51 -0700
Subject: [ee122] Directories with extensions
Message-ID: <20071031063951.GB5863@jobe.lan>

Hello-

Let's say I have two directories, "foo.avi" and "foo.txt". 

I'm assuming in either case, the directory's contents should be listed.
I'm checking mostly because if the extension determines the file-type,
then really, these shouldn't be interpreted as directories (even though
*nix couldn't care less).

Do we need to handle the case when an extension doesn't actually
correspond to the file's contents? Say I have a jpeg named "foo.txt"...
In this case, we blindly return "Content-Type: text/plain", right?

Thanks,

-- 
Chris Cowart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 824 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071030/f474838c/attachment.bin 

From jkwang at berkeley.edu  Tue Oct 30 23:41:51 2007
From: jkwang at berkeley.edu (Jeff Wang)
Date: Tue, 30 Oct 2007 23:41:51 -0700
Subject: [ee122] Persistent Connection Hanging
In-Reply-To: <200710310427.l9V4R5RO030614@pork.ICSI.Berkeley.EDU>
References: <200710310427.l9V4R5RO030614@pork.ICSI.Berkeley.EDU>
Message-ID: <C6B13988-865D-40E1-AA98-87B293B2B2BC@berkeley.edu>

How about when you request a file that is empty and the client is  
persistent?

The spec doesn't say if we should tack on anything in the entity. Not  
putting anything in the entity will cause the Safari/Firefox to hang.
Should we add <space><CRLF><CRLF>, or something else?

On Oct 30, 2007, at 9:27 PM, vern at cs.berkeley.edu wrote:

>> When I use Safari, with the keep-alive header, to request a file that
>> doesn't exist (ie. "/asdfsaf"),
>> the browser just hangs and keeps on loading.
>>
>> My server sends a 404 header, but no body.
>>
>> Apparently, Safari is waiting for more data, but never gets it.
>
> RFC 2616 states that a server SHOULD include an entity explaining the
> problem when returning a 40x status code.  Apparently Safari  
> requires this
> (even though given the SHOULD it should be prepared to deal with its
> absence).
>
> 		Vern


From jonliu at berkeley.edu  Tue Oct 30 23:48:38 2007
From: jonliu at berkeley.edu (Jonathan Liu)
Date: Tue, 30 Oct 2007 23:48:38 -0700
Subject: [ee122] Another Persistent Question -- does recv() block?
Message-ID: <25372C84-9173-4FD8-A64E-117E2322F1B6@berkeley.edu>

hi,

when using persistent connection, it seems like recv() blocks until  
the server closes the connection.  if this is true, how should we  
keep connections alive?

thank you,
jon

From dank at EECS.Berkeley.EDU  Wed Oct 31 00:18:36 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Wed, 31 Oct 2007 00:18:36 -0700
Subject: [ee122] File w/o extension + Directory listing question...
In-Reply-To: <AD725EF2-6B86-41B9-89BB-FE0910D8B7C3@gmail.com>
References: <AD725EF2-6B86-41B9-89BB-FE0910D8B7C3@gmail.com>
Message-ID: <f66da16e6df2.4727c9dc@EECS.Berkeley.EDU>



----- Original Message -----
From: Drew Lustro <drewlustro at gmail.com>
Date: Tuesday, October 30, 2007 10:17 pm
Subject: [ee122] File w/o extension + Directory listing question...

> So for directory listing, say the client requests "/foo"
> 
> If file "foo" exists, does that mean _no_matter_what_ we always 
> just  
> go "501 Not Implemented: /foo" because supported filetypes are  
> determined by filename extension?
Correct, its 501

> 
> If "foo" is a directory, we're supposed to return the contents of 
> the  
> ls command. The documentation _suggests_ we pipe the results of ls  
> into a file. Does this file need to be called something particular? 

You can do this however you want... So no, not called anything particular.

And the content type would be a text file, as answered before.


Daniel

> 
> Could we just call it .tmp_file_contents.txt and then return that 
> (ie:  
> end up doing HTTP/1.0 200 OK\nContent-Type: text/plain\nContent- 
> Length: 9999\n\r\nCONTENTS-OF-.tmp_file_contents.txt) and then 
> delete  
> the temporary file?
> 
> Thanks
> 
> Drew
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> 

From dank at EECS.Berkeley.EDU  Wed Oct 31 00:20:27 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Wed, 31 Oct 2007 00:20:27 -0700
Subject: [ee122] Directories with extensions
In-Reply-To: <20071031063951.GB5863@jobe.lan>
References: <20071031063951.GB5863@jobe.lan>
Message-ID: <f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>

Yes, list the directory's contents if the URL passed to you does refer to a directory, regardless of what the name 'looks like'.

Don't bother looking at the file's contents, just blindly return text/plain since the extension is .txt

Daniel
-------------- next part --------------
Hello-

Let's say I have two directories, "foo.avi" and "foo.txt". 

I'm assuming in either case, the directory's contents should be listed.
I'm checking mostly because if the extension determines the file-type,
then really, these shouldn't be interpreted as directories (even though
*nix couldn't care less).

Do we need to handle the case when an extension doesn't actually
correspond to the file's contents? Say I have a jpeg named "foo.txt"...
In this case, we blindly return "Content-Type: text/plain", right?

Thanks,

-- 
Chris Cowart
-------------- next part --------------
_______________________________________________
ee122 mailing list
ee122 at mailman.ICSI.Berkeley.EDU
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122

From dank at EECS.Berkeley.EDU  Wed Oct 31 00:24:29 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Wed, 31 Oct 2007 00:24:29 -0700
Subject: [ee122] Persistent Connection Hanging
In-Reply-To: <C6B13988-865D-40E1-AA98-87B293B2B2BC@berkeley.edu>
References: <200710310427.l9V4R5RO030614@pork.ICSI.Berkeley.EDU>
	<C6B13988-865D-40E1-AA98-87B293B2B2BC@berkeley.edu>
Message-ID: <f66df56c5648.4727cb3d@EECS.Berkeley.EDU>

If the file is empty, send the client a 0 byte file. That should work...

Daniel

----- Original Message -----
From: Jeff Wang <jkwang at berkeley.edu>
Date: Tuesday, October 30, 2007 11:41 pm
Subject: Re: [ee122] Persistent Connection Hanging

> How about when you request a file that is empty and the client is  
> persistent?
> 
> The spec doesn't say if we should tack on anything in the entity. 
> Not  
> putting anything in the entity will cause the Safari/Firefox to hang.
> Should we add <space><CRLF><CRLF>, or something else?
> 
> On Oct 30, 2007, at 9:27 PM, vern at cs.berkeley.edu wrote:
> 
> >> When I use Safari, with the keep-alive header, to request a file 
> that>> doesn't exist (ie. "/asdfsaf"),
> >> the browser just hangs and keeps on loading.
> >>
> >> My server sends a 404 header, but no body.
> >>
> >> Apparently, Safari is waiting for more data, but never gets it.
> >
> > RFC 2616 states that a server SHOULD include an entity explaining 
> the> problem when returning a 40x status code.  Apparently Safari  
> > requires this
> > (even though given the SHOULD it should be prepared to deal with its
> > absence).
> >
> >         	Vern
> 
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> 

From dank at EECS.Berkeley.EDU  Wed Oct 31 00:25:57 2007
From: dank at EECS.Berkeley.EDU (Carrell Killebrew)
Date: Wed, 31 Oct 2007 00:25:57 -0700
Subject: [ee122] Another Persistent Question -- does recv() block?
In-Reply-To: <25372C84-9173-4FD8-A64E-117E2322F1B6@berkeley.edu>
References: <25372C84-9173-4FD8-A64E-117E2322F1B6@berkeley.edu>
Message-ID: <f688cb3b5f8a.4727cb95@EECS.Berkeley.EDU>

I believe you should be familiar with select()...
or type 'man recv' and check the flags that you can use with recv()

Daniel

----- Original Message -----
From: Jonathan Liu <jonliu at berkeley.edu>
Date: Tuesday, October 30, 2007 11:48 pm
Subject: [ee122] Another Persistent Question -- does recv() block?

> hi,
> 
> when using persistent connection, it seems like recv() blocks until 
> 
> the server closes the connection.  if this is true, how should we  
> keep connections alive?
> 
> thank you,
> jon
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> 

From merry_c at berkeley.edu  Wed Oct 31 00:30:42 2007
From: merry_c at berkeley.edu (Merry Choi)
Date: Wed, 31 Oct 2007 00:30:42 -0700
Subject: [ee122] wireshark with my server
In-Reply-To: <f688cb3b5f8a.4727cb95@EECS.Berkeley.EDU>
Message-ID: <E1In828-0004yy-4C@fe1.calmail>

I can't seem to get an HTTP for protocol type in wireshark when I use my own
server, possibly because I'm not using port 80? I'm not sure. All I get are
TCP packets. Is this normal even when data is definitely being sent? 


From ccowart at berkeley.edu  Wed Oct 31 00:46:16 2007
From: ccowart at berkeley.edu (Christopher Cowart)
Date: Wed, 31 Oct 2007 00:46:16 -0700
Subject: [ee122] Directories with extensions
In-Reply-To: <f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>
References: <20071031063951.GB5863@jobe.lan>
	<f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>
Message-ID: <20071031074615.GD5863@jobe.lan>

On Wed, Oct 31, 2007 at 12:20:27AM -0700, Carrell Killebrew wrote:
> Yes, list the directory's contents if the URL passed to you does 
> refer to a directory, regardless of what the name 'looks like'.
> 
> Don't bother looking at the file's contents, just blindly return 
> text/plain since the extension is .txt

Here's another case:

Assume /index.html is a directory.

When the client asks for /, do we:
  a) ls index.html
  b) recurse, so look for /index.html/index.html, and ls /index.html if
     index.html/index.html doesn't exist
  c) not worry about it because it's a really obnoxious corner case that
     doubles the length of the logic and you're a nice guy who isn't 
     going to write any such test cases

-- 
Chris Cowart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 824 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/9b144140/attachment.bin 

From cardi at berkeley.edu  Wed Oct 31 00:48:38 2007
From: cardi at berkeley.edu (Calvin A)
Date: Wed, 31 Oct 2007 00:48:38 -0700 (PDT)
Subject: [ee122] Directories with extensions
In-Reply-To: <20071031074615.GD5863@jobe.lan>
References: <20071031063951.GB5863@jobe.lan>
	<f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>
	<20071031074615.GD5863@jobe.lan>
Message-ID: <3057.71.146.14.38.1193816918.squirrel@calmail.berkeley.edu>

> On Wed, Oct 31, 2007 at 12:20:27AM -0700, Carrell Killebrew wrote:
>> Yes, list the directory's contents if the URL passed to you does
>> refer to a directory, regardless of what the name 'looks like'.
>>
>> Don't bother looking at the file's contents, just blindly return
>> text/plain since the extension is .txt
>
> Here's another case:
>
> Assume /index.html is a directory.
>
> When the client asks for /, do we:
>   a) ls index.html
>   b) recurse, so look for /index.html/index.html, and ls /index.html if
>      index.html/index.html doesn't exist
>   c) not worry about it because it's a really obnoxious corner case that
>      doubles the length of the logic and you're a nice guy who isn't
>      going to write any such test cases
>
And another:

If we have

 GET /foo.avi

I thought we would just return "501 Not Implemented". Are we to check if
it exists as a directory first? If so, does that mean we need to append
/index.html and check if that exists, then treat it as a directory and
list the contents (if permitted)?

In the case when we have

 GET /foo.avi/

it seems more clear that we check if the folder exists, then look for
index.html, then list the directory's contents (if I'm not mistaken).

Thanks,
Calvin
> --
> Chris Cowart
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>



From drewlustro at gmail.com  Wed Oct 31 02:21:33 2007
From: drewlustro at gmail.com (Drew Lustro)
Date: Wed, 31 Oct 2007 02:21:33 -0700
Subject: [ee122] Segfault Madness (need expert)
Message-ID: <EC5E17C8-6A36-4369-B1CB-DA636005243B@gmail.com>

This may be one of the most difficult to explain problems, but I'll  
try.  I've been working on the server and everything was OK and then I  
started getting segfaults. I was confused since the recent changes did  
NOT involve any malloc'ing / freeing of any sort! After some tedious,  
tedious commenting and uncommenting (because Eclipse's debugger was  
totally useless), I found that if I uncomment a single declaration,  
the segfaults vanish.

I added this BOOL declaration line to the top of  
processClientInput(client):

int processClientInput(sockAndBufs &client)
{
	int bytes = consumeRequestLine(client);
	char ** uri;
	char * uri_string;
		   bool keepAlive = false; // THIS, OF ALL THINGS IS WHAT CAUSES THE  
SEGFAULTING

	// ... tons more code
	// note: uri and uri_string do involve mallocing, but did not give me  
any trouble in the past


Can any C/C++ Guru shed some light on this? Why would commenting out  
the "bool" line lead to no segfaulting? Such an obscure problem is  
throwing me off so hard that I'm starting to believe this project is  
just a get-pissed-off-at-c project rather than us learning anything  
new about socket programming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/0968a068/attachment.html 

From benjlau at berkeley.edu  Wed Oct 31 02:29:10 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Wed, 31 Oct 2007 02:29:10 -0700 (PDT)
Subject: [ee122]  lab
Message-ID: <3377.71.132.220.30.1193822950.squirrel@calmail.berkeley.edu>

I can't do Part 21 and 22 of the lab.  I get ESP packets whenever I have
my client on sphere and my server on ilinux.  I can't have them both on
ilinux and then look at the adaptor because, for some reason, I cannot
access tcpdump or tshark.  "which tshark" for example gives me a bad value
at the command line.  I can't have them both on sphere because then I get
the message

sphere [4] /share/b/ee122 > tshark -w ~/tracefile -i lo0 host
sphere.cs.berkeley.edu and port 10000
tshark: The capture session could not be initiated (lo0: No DLPI device
found).

ilinux3 [9] ~ > which tshark
tshark: Command not found.
ilinux3 [10] ~ > which tcpdump
tcpdump: Command not found.



From vern at cs.berkeley.edu  Wed Oct 31 04:05:18 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 04:05:18 -0700
Subject: [ee122] Persistent Connection Hanging
In-Reply-To: <C6B13988-865D-40E1-AA98-87B293B2B2BC@berkeley.edu> (Tue,
	30 Oct 2007 23:41:51 PDT).
Message-ID: <200710311105.l9VB5M1Z005075@pork.ICSI.Berkeley.EDU>

> How about when you request a file that is empty and the client is  
> persistent?

Content-length: 0, or the server just denies the persistent connection
and closes the connection.

> The spec doesn't say if we should tack on anything in the entity.

Right.  This was an omission on our part.  (Note that it's a SHOULD, not
a MUST, in the spec.)

> Not  
> putting anything in the entity will cause the Safari/Firefox to hang.
> Should we add <space><CRLF><CRLF>, or something else?

If you want to implement this, any valid entity will do.  You could for
example return something like like the following (which I took from the
lightweight "thttpd" server):

	HTTP/1.0 404 Not Found
	Content-Type: text/html
	Date: Wed, 31 Oct 2007 11:01:09 GMT
	Last-Modified: Wed, 31 Oct 2007 11:01:09 GMT
	Connection: close

	<HTML>
	<HEAD><TITLE>404 Not Found</TITLE></HEAD>
	<BODY>
	<H2>404 Not Found</H2>
	The requested URL '/does-not-exist-test' was not found on this server.
	<HR>
	</BODY>
	</HTML>

- Vern

From ofer at berkeley.edu  Wed Oct 31 04:23:46 2007
From: ofer at berkeley.edu (Ofer Sadgat)
Date: Wed, 31 Oct 2007 04:23:46 -0700
Subject: [ee122] Segfault Madness (need expert)
In-Reply-To: <EC5E17C8-6A36-4369-B1CB-DA636005243B@gmail.com>
References: <EC5E17C8-6A36-4369-B1CB-DA636005243B@gmail.com>
Message-ID: <001b01c81bb0$8372c4f0$8a584ed0$@edu>

This is a bug that happened to me a while back. The reason that the bug is
so hard to find is because it errors out on code that did not cause it. I'm
being a bit vague. To be more specific, what happened to me was that an
earlier instruction "segfaulted" BUT there was no error thrown until the
random insertion of some line. When I say segfaulted earlier that could be
one of numerous things. 1. You went out of bounds on memory that was given
to you. 2. You tried to write to some ptr whose value got screwed up and now
you're writing to some potentially deadly place in memory. 3. You try and
free a ptr that has been offset (I think that the last one does this, but Im
not sure).

 

Hope this help.at least a bit.

-Ofer

 

From: ee122-bounces at ICSI.Berkeley.EDU
[mailto:ee122-bounces at ICSI.Berkeley.EDU] On Behalf Of Drew Lustro
Sent: Wednesday, October 31, 2007 2:22 AM
To: ee122 at ICSI.Berkeley.EDU
Subject: [ee122] Segfault Madness (need expert)

 

This may be one of the most difficult to explain problems, but I'll try.
I've been working on the server and everything was OK and then I started
getting segfaults. I was confused since the recent changes did NOT involve
any malloc'ing / freeing of any sort! After some tedious, tedious commenting
and uncommenting (because Eclipse's debugger was totally useless), I found
that if I uncomment a single declaration, the segfaults vanish.

 

I added this BOOL declaration line to the top of processClientInput(client):

 

int processClientInput(sockAndBufs &client)

{

       int bytes = consumeRequestLine(client);

       char ** uri;

       char * uri_string;

                           bool keepAlive = false; // THIS, OF ALL THINGS IS
WHAT CAUSES THE SEGFAULTING

 

       // ... tons more code

       // note: uri and uri_string do involve mallocing, but did not give me
any trouble in the past

 

 

Can any C/C++ Guru shed some light on this? Why would commenting out the
"bool" line lead to no segfaulting? Such an obscure problem is throwing me
off so hard that I'm starting to believe this project is just a
get-pissed-off-at-c project rather than us learning anything new about
socket programming.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/e5f6d8be/attachment-0001.html 

From drewlustro at gmail.com  Wed Oct 31 12:54:48 2007
From: drewlustro at gmail.com (Drew Lustro)
Date: Wed, 31 Oct 2007 12:54:48 -0700
Subject: [ee122] XXXtension??!!
Message-ID: <A74D5820-086D-4FCA-8A31-8FCFA697AFF6@gmail.com>

Can we have another? Pleeeeeeeeeeeeaaaaaaasssssssssseeee?

(less than half-joking)

Thanks prof

From vern at cs.berkeley.edu  Wed Oct 31 12:59:53 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 12:59:53 -0700
Subject: [ee122] wireshark with my server
In-Reply-To: <E1In828-0004yy-4C@fe1.calmail> (Wed, 31 Oct 2007 00:30:42 PDT).
Message-ID: <200710311959.l9VJxuX8013859@pork.ICSI.Berkeley.EDU>

> I can't seem to get an HTTP for protocol type in wireshark when I use my own
> server, possibly because I'm not using port 80?

That's indeed why.  Wireshark infers the protocol type to display based
on the port number used.

		Vern

From vern at cs.berkeley.edu  Wed Oct 31 13:00:03 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 13:00:03 -0700
Subject: [ee122] Another Persistent Question -- does recv() block?
In-Reply-To: <25372C84-9173-4FD8-A64E-117E2322F1B6@berkeley.edu> (Tue,
	30 Oct 2007 23:48:38 PDT).
Message-ID: <200710312000.l9VK06YQ013873@pork.ICSI.Berkeley.EDU>

> when using persistent connection, it seems like recv() blocks until  
> the server closes the connection.

Rather, it blocks when there's no data to read.  You might be running into
a situation where you've called it even though your server isn't going to
send anything more (like a 4xx response for which the server isn't
including an entity).

> if this is true, how should we  
> keep connections alive?

I'm not sure what you mean by "alive" here.  TCP connections stay established
indefinitely.

		Vern

From pbogatsky at berkeley.edu  Wed Oct 31 13:05:52 2007
From: pbogatsky at berkeley.edu (Peter Bogatsky)
Date: Wed, 31 Oct 2007 13:05:52 -0700
Subject: [ee122]  What to save on client for extrapolated request
Message-ID: <18208FA4-AB89-43D8-94D4-C36835DA4FBF@berkeley.edu>

Assume ./dir/index.html is a valid file on the server. The client  
requests /dir, and we find that ./dir/index.html exists, so we send  
it. Does the client save this file as dir or index.html? I'm thinking  
it should save it as dir since the client doesn't know about the  
magic we did behind the scenes in appending the /index.html to the  
request, but logically, the client should want to save it as  
index.html since it contains html.

Thanks,
Peter

From ofer at berkeley.edu  Wed Oct 31 14:10:36 2007
From: ofer at berkeley.edu (Ofer Sadgat)
Date: Wed, 31 Oct 2007 14:10:36 -0700
Subject: [ee122] Persistant Connections
Message-ID: <000301c81c02$83b5ef30$8b21cd90$@edu>

If you have a connection to a server which you send a request and request a
persistent connection but the server refuses. In its response it includes a
Content-Length header. As the client I parse this and receive content-length
data. However, Once I have received the data I continue on with no more
calls to read. However, the server now closes the connection and the client
has no idea of this event. The client then makes a request to the same
server and noticing that that is where it last connected it doesn't
establish a new connection. The following recv call fails.

 

How do I fix this? Is there a way to check whether or not a server has
closed the connection without receiving data?

 

Thanks,

Ofer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/a08d06a9/attachment.html 

From leeallen at berkeley.edu  Wed Oct 31 14:21:33 2007
From: leeallen at berkeley.edu (Allen Lee)
Date: Wed, 31 Oct 2007 14:21:33 -0700
Subject: [ee122] Status code precedence
Message-ID: <59f1e110710311421tf054c13m702c1d0d9da20a9f@mail.gmail.com>

I'm not sure if this question has been asked yet:

If the server gets the request

GET /foo.avi HTTP/1.0

and foo.avi does not exist on the server, should the status code be 404 or
501?

If foo.avi does exist on the server, but we don't have read permission,
should the status code be 403 or 501?

Thanks,
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/25e40fca/attachment.html 

From pbogatsky at berkeley.edu  Wed Oct 31 15:03:58 2007
From: pbogatsky at berkeley.edu (Peter Bogatsky)
Date: Wed, 31 Oct 2007 15:03:58 -0700
Subject: [ee122]  What to save to disk?
Message-ID: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>

If the client requests a directory, and the server responds with the  
result of the 'ls' command, does the client save this output to disk  
(using the special cases of simple file names in the spec ie. 'dir',  
'dot', 'dotdot', etc.), or does it just print it out to stdout? Also,  
if it does save the response to disk, what should the Content-Type  
header be? I'm assuming text/txt.

Thanks,
Peter

From vern at cs.berkeley.edu  Wed Oct 31 15:08:24 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 15:08:24 -0700
Subject: [ee122] Segfault Madness (need expert)
In-Reply-To: <001b01c81bb0$8372c4f0$8a584ed0$@edu> (Wed,
	31 Oct 2007 04:23:46 PDT).
Message-ID: <200710312208.l9VM8SaM015994@pork.ICSI.Berkeley.EDU>

Yes, this (unfortunately) is a classic C pointer error, where memory is
getting overwritten and the problem only manifests later when the trashed
value is accessed.  In Drew's code, adding the new variable changes the
stack layout.  This suggests (but not definitively) that in this case the
problem is something being overrun on the stack due to a local buffer,
rather than a heap pointer managed by malloc/free.

One way to try to find problems like this is to use gcc -g -Wall in order
to catch problems that can be found at compile time, and then to execute
inside of gdb, which will at least show the location of where the problem
*manifests* (-g turns on debugging symbols).

I believe the instructional machines also have some more powerful tools
available such as Purify or Coverity.  But these will have a learning curve
associated with figuring out how to use them.

		Vern

From haley.ng at gmail.com  Wed Oct 31 15:01:50 2007
From: haley.ng at gmail.com (Haley Nguyen)
Date: Wed, 31 Oct 2007 15:01:50 -0700
Subject: [ee122] Persistant Connections
In-Reply-To: <000301c81c02$83b5ef30$8b21cd90$@edu>
References: <000301c81c02$83b5ef30$8b21cd90$@edu>
Message-ID: <95aaa0710710311501g28f77545wb79ae3f5bfda92f8@mail.gmail.com>

On the client side, the socket is blocking, so the recv on the client side
is blocking. Therefore, if recv return 0, it means that the other side close
the connection. This is where I get the answer:
http://mkssoftware.com/docs/man3/recv.3.asp.

On 10/31/07, Ofer Sadgat <ofer at berkeley.edu> wrote:
>
>  If you have a connection to a server which you send a request and request
> a persistent connection but the server refuses. In its response it includes
> a Content-Length header. As the client I parse this and receive
> content-length data. However, Once I have received the data I continue on
> with no more calls to read. However, the server now closes the connection
> and the client has no idea of this event. The client then makes a request to
> the same server and noticing that that is where it last connected it doesn't
> establish a new connection. The following recv call fails.
>
>
>
> How do I fix this? Is there a way to check whether or not a server has
> closed the connection without receiving data?
>
>
>
> Thanks,
>
> Ofer
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>


-- 
Haley Nguyen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/e1ec513c/attachment.html 

From vern at cs.berkeley.edu  Wed Oct 31 15:15:03 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 15:15:03 -0700
Subject: [ee122] XXXtension??!!
In-Reply-To: <A74D5820-086D-4FCA-8A31-8FCFA697AFF6@gmail.com> (Wed,
	31 Oct 2007 12:54:48 PDT).
Message-ID: <200710312215.l9VMF7ba016107@pork.ICSI.Berkeley.EDU>

> Can we have another? Pleeeeeeeeeeeeaaaaaaasssssssssseeee?

No, I'm afraid not.

		Vern

From dank at eecs.berkeley.edu  Wed Oct 31 15:15:14 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:15:14 -0700
Subject: [ee122] Directories with extensions
In-Reply-To: <20071031074615.GD5863@jobe.lan>
References: <20071031063951.GB5863@jobe.lan>
	<f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>
	<20071031074615.GD5863@jobe.lan>
Message-ID: <4728FE72.5050103@eecs.berkeley.edu>



Christopher Cowart wrote:
> On Wed, Oct 31, 2007 at 12:20:27AM -0700, Carrell Killebrew wrote:
>   
>> Yes, list the directory's contents if the URL passed to you does 
>> refer to a directory, regardless of what the name 'looks like'.
>>
>> Don't bother looking at the file's contents, just blindly return 
>> text/plain since the extension is .txt
>>     
>
> Here's another case:
>
> Assume /index.html is a directory.
>
> When the client asks for /, do we:
>   
Good question. Since they asked for / and not actually for /index.html, 
and since index.html is not a file, do step 3. Ie: treat '/' as a 
directory and do 'ls' on it.
>   a) ls index.html
>   b) recurse, so look for /index.html/index.html, and ls /index.html if
>      index.html/index.html doesn't exist
>   c) not worry about it because it's a really obnoxious corner case that
>      doubles the length of the logic and you're a nice guy who isn't 
>      going to write any such test cases
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From dank at berkeley.edu  Wed Oct 31 15:18:34 2007
From: dank at berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:18:34 -0700
Subject: [ee122] Directories with extensions
In-Reply-To: <3057.71.146.14.38.1193816918.squirrel@calmail.berkeley.edu>
References: <20071031063951.GB5863@jobe.lan>
	<f67ffc672afe.4727ca4b@EECS.Berkeley.EDU>
	<20071031074615.GD5863@jobe.lan>
	<3057.71.146.14.38.1193816918.squirrel@calmail.berkeley.edu>
Message-ID: <4728FF3A.9020506@berkeley.edu>



Calvin A wrote:
>> On Wed, Oct 31, 2007 at 12:20:27AM -0700, Carrell Killebrew wrote:
>>     
>>> Yes, list the directory's contents if the URL passed to you does
>>> refer to a directory, regardless of what the name 'looks like'.
>>>
>>> Don't bother looking at the file's contents, just blindly return
>>> text/plain since the extension is .txt
>>>       
>> Here's another case:
>>
>> Assume /index.html is a directory.
>>
>> When the client asks for /, do we:
>>   a) ls index.html
>>   b) recurse, so look for /index.html/index.html, and ls /index.html if
>>      index.html/index.html doesn't exist
>>   c) not worry about it because it's a really obnoxious corner case that
>>      doubles the length of the logic and you're a nice guy who isn't
>>      going to write any such test cases
>>
>>     
> And another:
>
> If we have
>
>  GET /foo.avi
>
> I thought we would just return "501 Not Implemented". Are we to check if
> it exists as a directory first? 
Correct, don't assume a URI refers to a file just because it has a 
recognized extension. You need to use ls to figure out if it's really a 
file or directory.
So if /foo.avi is a directory, then you will try to append /index.html 
to the URI, etc.
> If so, does that mean we need to append
> /index.html and check if that exists, then treat it as a directory and
> list the contents (if permitted)?
>
> In the case when we have
>
>  GET /foo.avi/
>
> it seems more clear that we check if the folder exists, then look for
> index.html, then list the directory's contents (if I'm not mistaken).
>   
The steps you suggest are correct.

Daniel
> Thanks,
> Calvin
>   
>> --
>> Chris Cowart
>> _______________________________________________
>> ee122 mailing list
>> ee122 at mailman.ICSI.Berkeley.EDU
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>>
>>     
>
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:36:19 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:36:19 -0700
Subject: [ee122] Segfault Madness (need expert)
In-Reply-To: <200710312208.l9VM8SaM015994@pork.ICSI.Berkeley.EDU>
References: <200710312208.l9VM8SaM015994@pork.ICSI.Berkeley.EDU>
Message-ID: <47290363.50005@eecs.berkeley.edu>

I don't know if theres an equivalent to this in UNIX, but when I'm 
writing windows code, theres some special memory debugging flags that 
you can set.
_CrtSetDbgFlag
Then the c runtime library can do various useful things for you, such as 
putting boundaries around allocated memory, and checking that you 
haven't written outside your allocated memory whenever you (de)allocate. 
It can do some other nice things as well.

Daniel

vern at EECS.Berkeley.EDU wrote:
> Yes, this (unfortunately) is a classic C pointer error, where memory is
> getting overwritten and the problem only manifests later when the trashed
> value is accessed.  In Drew's code, adding the new variable changes the
> stack layout.  This suggests (but not definitively) that in this case the
> problem is something being overrun on the stack due to a local buffer,
> rather than a heap pointer managed by malloc/free.
>
> One way to try to find problems like this is to use gcc -g -Wall in order
> to catch problems that can be found at compile time, and then to execute
> inside of gdb, which will at least show the location of where the problem
> *manifests* (-g turns on debugging symbols).
>
> I believe the instructional machines also have some more powerful tools
> available such as Purify or Coverity.  But these will have a learning curve
> associated with figuring out how to use them.
>
> 		Vern
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:37:54 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:37:54 -0700
Subject: [ee122] What to save to disk?
In-Reply-To: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>
References: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>
Message-ID: <472903C2.2060103@eecs.berkeley.edu>



Peter Bogatsky wrote:
> If the client requests a directory, and the server responds with the  
> result of the 'ls' command, does the client save this output to disk  
>   
Yes
> (using the special cases of simple file names in the spec ie. 'dir',  
> 'dot', 'dotdot', etc.), or does it just print it out to stdout? Also,  
> if it does save the response to disk, what should the Content-Type  
> header be? 

> I'm assuming text/txt.
>   
Correct again. (this question has been answered before here on 
newsgroup.... :)

Daniel
> Thanks,
> Peter
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:38:30 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:38:30 -0700
Subject: [ee122] Status code precedence
In-Reply-To: <59f1e110710311421tf054c13m702c1d0d9da20a9f@mail.gmail.com>
References: <59f1e110710311421tf054c13m702c1d0d9da20a9f@mail.gmail.com>
Message-ID: <472903E6.3060006@eecs.berkeley.edu>



Allen Lee wrote:
> I'm not sure if this question has been asked yet:
>
> If the server gets the request
>
> GET /foo.avi HTTP/1.0
>
> and foo.avi does not exist on the server, should the status code be 
> 404 or 501?
It should be the does not exist error.
>
> If foo.avi does exist on the server, but we don't have read 
> permission, should the status code be 403 or 501?
No permissions error

Daniel
>
> Thanks,
> Allen
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:40:07 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:40:07 -0700
Subject: [ee122] Persistant Connections
In-Reply-To: <95aaa0710710311501g28f77545wb79ae3f5bfda92f8@mail.gmail.com>
References: <000301c81c02$83b5ef30$8b21cd90$@edu>
	<95aaa0710710311501g28f77545wb79ae3f5bfda92f8@mail.gmail.com>
Message-ID: <47290447.9000005@eecs.berkeley.edu>

You could call recv() with the non-blocking and msg_peek flags to see if 
the socket is open without blocking or removing any data from the recv() 
buffer.

Daniel

Haley Nguyen wrote:
> On the client side, the socket is blocking, so the recv on the client 
> side is blocking. Therefore, if recv return 0, it means that the other 
> side close the connection. This is where I get the answer: 
> http://mkssoftware.com/docs/man3/recv.3.asp.
>
> On 10/31/07, *Ofer Sadgat* <ofer at berkeley.edu 
> <mailto:ofer at berkeley.edu>> wrote:
>
>     If you have a connection to a server which you send a request and
>     request a persistent connection but the server refuses. In its
>     response it includes a Content-Length header. As the client I
>     parse this and receive content-length data. However, Once I have
>     received the data I continue on with no more calls to read.
>     However, the server now closes the connection and the client has
>     no idea of this event. The client then makes a request to the same
>     server and noticing that that is where it last connected it
>     doesn't establish a new connection. The following recv call fails.
>
>      
>
>     How do I fix this? Is there a way to check whether or not a server
>     has closed the connection without receiving data?
>
>      
>
>     Thanks,
>
>     Ofer
>
>
>     _______________________________________________
>     ee122 mailing list
>     ee122 at mailman.ICSI.Berkeley.EDU
>     <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
>     http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>
>
>
> -- 
> Haley Nguyen
> ------------------------------------------------------------------------
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:48:11 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:48:11 -0700
Subject: [ee122] Segfault Madness (need expert)
In-Reply-To: <200710312208.l9VM8SaM015994@pork.ICSI.Berkeley.EDU>
References: <200710312208.l9VM8SaM015994@pork.ICSI.Berkeley.EDU>
Message-ID: <4729062B.7040203@eecs.berkeley.edu>

It sounds like stack overrun to me to, so one thing that /may /work (I 
have never tried something like this). Hopefully if you compile in full 
debugging mode with no optimizations the compiler will preserve your 
stack ordering. So try this:

void SomeFunction()
{
int topStack = 0xfeedbabe;
<some other stack variables you actually care about>
int bottomStack = 0xdeadbeef;

<do stuff in your function>

<before you take any and *all *return paths from your function>
assert(topStack == 0xfeedbabe && bottomStack==0xdeadbeef);
}

It may work, shrug. Worth trying new stuff when hitting your head 
against a wall, I suppose. Hopefully it will detect if your function or 
any functions it calls are writing outside their stack space. You can of 
course make the top and bottom stack variables into arrays if you want a 
larger safety margin (in case the offending function might not be 
writing contiguous bytes).

Daniel

vern at EECS.Berkeley.EDU wrote:
> Yes, this (unfortunately) is a classic C pointer error, where memory is
> getting overwritten and the problem only manifests later when the trashed
> value is accessed.  In Drew's code, adding the new variable changes the
> stack layout.  This suggests (but not definitively) that in this case the
> problem is something being overrun on the stack due to a local buffer,
> rather than a heap pointer managed by malloc/free.
>
> One way to try to find problems like this is to use gcc -g -Wall in order
> to catch problems that can be found at compile time, and then to execute
> inside of gdb, which will at least show the location of where the problem
> *manifests* (-g turns on debugging symbols).
>
> I believe the instructional machines also have some more powerful tools
> available such as Purify or Coverity.  But these will have a learning curve
> associated with figuring out how to use them.
>
> 		Vern
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From vern at cs.berkeley.edu  Wed Oct 31 15:50:37 2007
From: vern at cs.berkeley.edu (vern at cs.berkeley.edu)
Date: Wed, 31 Oct 2007 15:50:37 -0700
Subject: [ee122] Persistant Connections
In-Reply-To: <47290447.9000005@eecs.berkeley.edu> (Wed,
	31 Oct 2007 15:40:07 PDT).
Message-ID: <200710312250.l9VMoeeV016732@pork.ICSI.Berkeley.EDU>

> You could call recv() with the non-blocking and msg_peek flags to see if 
> the socket is open without blocking or removing any data from the recv() 
> buffer.

To be clear, however: this level of error-checking is *not* required!

		Vern

From dank at eecs.berkeley.edu  Wed Oct 31 15:56:37 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:56:37 -0700
Subject: [ee122] (no subject)
In-Reply-To: <61224.67.169.102.122.1193781028.squirrel@calmail.berkeley.edu>
References: <61224.67.169.102.122.1193781028.squirrel@calmail.berkeley.edu>
Message-ID: <47290825.1010207@eecs.berkeley.edu>

You should be case insensitive, and accept one or more spaces or 
horizontal tabs (\t) between the ':' and keep-alive or chunked.

Daniel

miken087 at berkeley.edu wrote:
> For the parsing of the "Connection: Keep-Alive" and "Transfer-Encoding:
> chunked" headers, does the casing matter? Also does the number of spaces
> between each word matter? For example would "connection:    Keep-aLive" be
> valid? Thanks.
>
> Michael Ngo
>
>
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>   

From dank at eecs.berkeley.edu  Wed Oct 31 15:59:01 2007
From: dank at eecs.berkeley.edu (Daniel Killebrew)
Date: Wed, 31 Oct 2007 15:59:01 -0700
Subject: [ee122] Status code precedence
In-Reply-To: <472903E6.3060006@eecs.berkeley.edu>
References: <59f1e110710311421tf054c13m702c1d0d9da20a9f@mail.gmail.com>
	<472903E6.3060006@eecs.berkeley.edu>
Message-ID: <472908B5.4020701@eecs.berkeley.edu>



Daniel Killebrew wrote:
> Allen Lee wrote:
>   
>> I'm not sure if this question has been asked yet:
>>
>> If the server gets the request
>>
>> GET /foo.avi HTTP/1.0
>>
>> and foo.avi does not exist on the server, should the status code be 
>> 404 or 501?
>>     
> It should be the does not exist error.
>   
>> If foo.avi does exist on the server, but we don't have read 
>> permission, should the status code be 403 or 501?
>>     
> No permissions error
>   
To clarify: I mean the error should be the 'no permissions error', 
whichever error that is.

Daniel

From nescionomen at gmail.com  Wed Oct 31 16:45:46 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Wed, 31 Oct 2007 16:45:46 -0700
Subject: [ee122] What to save to disk?
In-Reply-To: <472903C2.2060103@eecs.berkeley.edu>
References: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>
	<472903C2.2060103@eecs.berkeley.edu>
Message-ID: <ee4042d90710311645k1d36bb0dqd65a18712e3da09c@mail.gmail.com>

Why is it text/txt instead of text/plain?  I thought text/plain is what is
used in real life-- if not, when do we use text/plain in real life instead
of text/txt?

On 10/31/07, Daniel Killebrew <dank at eecs.berkeley.edu> wrote:
>
>
>
> Peter Bogatsky wrote:
> > If the client requests a directory, and the server responds with the
> > result of the 'ls' command, does the client save this output to disk
> >
> Yes
> > (using the special cases of simple file names in the spec ie. 'dir',
> > 'dot', 'dotdot', etc.), or does it just print it out to stdout? Also,
> > if it does save the response to disk, what should the Content-Type
> > header be?
>
> > I'm assuming text/txt.
> >
> Correct again. (this question has been answered before here on
> newsgroup.... :)
>
> Daniel
> > Thanks,
> > Peter
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
> >
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/0e62081b/attachment.html 

From jkwang at berkeley.edu  Wed Oct 31 17:06:09 2007
From: jkwang at berkeley.edu (Jeff Wang)
Date: Wed, 31 Oct 2007 17:06:09 -0700
Subject: [ee122] What to save to disk?
In-Reply-To: <ee4042d90710311645k1d36bb0dqd65a18712e3da09c@mail.gmail.com>
References: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>
	<472903C2.2060103@eecs.berkeley.edu>
	<ee4042d90710311645k1d36bb0dqd65a18712e3da09c@mail.gmail.com>
Message-ID: <22A1724E-6749-46FE-9F79-7BED01E062F8@berkeley.edu>

this wasn't specified on the spec, so I also just used text/plain  
also since that's what I see servers using in "real life" ...
is this ok?

On Oct 31, 2007, at 4:45 PM, Nescio Nomen wrote:

> Why is it text/txt instead of text/plain?  I thought text/plain is  
> what is used in real life-- if not, when do we use text/plain in  
> real life instead of text/txt?
>
> On 10/31/07, Daniel Killebrew <dank at eecs.berkeley.edu> wrote:
>
>
> Peter Bogatsky wrote:
> > If the client requests a directory, and the server responds with the
> > result of the 'ls' command, does the client save this output to disk
> >
> Yes
> > (using the special cases of simple file names in the spec ie. 'dir',
> > 'dot', 'dotdot', etc.), or does it just print it out to stdout?  
> Also,
> > if it does save the response to disk, what should the Content-Type
> > header be?
>
> > I'm assuming text/txt.
> >
> Correct again. (this question has been answered before here on
> newsgroup.... :)
>
> Daniel
> > Thanks,
> > Peter
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
> >
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/efd0ef3a/attachment-0001.html 

From fowler at eecs.berkeley.edu  Wed Oct 31 17:10:47 2007
From: fowler at eecs.berkeley.edu (Lisa Fowler)
Date: Wed, 31 Oct 2007 17:10:47 -0700
Subject: [ee122] What to save to disk?
In-Reply-To: <22A1724E-6749-46FE-9F79-7BED01E062F8@berkeley.edu>
References: <14BE779E-1F06-420F-A7A7-0DB03BF559EE@berkeley.edu>
	<472903C2.2060103@eecs.berkeley.edu>
	<ee4042d90710311645k1d36bb0dqd65a18712e3da09c@mail.gmail.com>
	<22A1724E-6749-46FE-9F79-7BED01E062F8@berkeley.edu>
Message-ID: <330471bf0710311710h720472bbx42a1270a15a049d5@mail.gmail.com>

text/plain please!

On Oct 31, 2007 5:06 PM, Jeff Wang <jkwang at berkeley.edu> wrote:
> this wasn't specified on the spec, so I also just used text/plain also since
> that's what I see servers using in "real life" ...
> is this ok?
>
>
>
>
> On Oct 31, 2007, at 4:45 PM, Nescio Nomen wrote:
> Why is it text/txt instead of text/plain?  I thought text/plain is what is
> used in real life-- if not, when do we use text/plain in real life instead
> of text/txt?
>
> On 10/31/07, Daniel Killebrew <dank at eecs.berkeley.edu> wrote:
> >
> >
> > Peter Bogatsky wrote:
> > > If the client requests a directory, and the server responds with the
> > > result of the 'ls' command, does the client save this output to disk
> > >
> > Yes
> > > (using the special cases of simple file names in the spec ie. 'dir',
> > > 'dot', 'dotdot', etc.), or does it just print it out to stdout? Also,
> > > if it does save the response to disk, what should the Content-Type
> > > header be?
> >
> > > I'm assuming text/txt.
> > >
> > Correct again. (this question has been answered before here on
> > newsgroup.... :)
> >
> > Daniel
> > > Thanks,
> > > Peter
> > > _______________________________________________
> > > ee122 mailing list
> > > ee122 at mailman.ICSI.Berkeley.EDU
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> > >
> > >
> > _______________________________________________
> > ee122 mailing list
> > ee122 at mailman.ICSI.Berkeley.EDU
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>

From benjlau at berkeley.edu  Wed Oct 31 22:26:29 2007
From: benjlau at berkeley.edu (benjlau at berkeley.edu)
Date: Wed, 31 Oct 2007 22:26:29 -0700 (PDT)
Subject: [ee122]  bug in submission handling script?
Message-ID: <2403.71.132.223.146.1193894789.squirrel@calmail.berkeley.edu>

When I submit, I get the following:

Submitting to ee122-ra ....
tar: ./K: No such file or directory
sh: R.h: not found
Submission complete.  You should be hearing from us.

What's that with tar and sh?  Did the system really catch the submission?



From nescionomen at gmail.com  Wed Oct 31 22:38:25 2007
From: nescionomen at gmail.com (Nescio Nomen)
Date: Wed, 31 Oct 2007 22:38:25 -0700
Subject: [ee122] bug in submission handling script?
In-Reply-To: <2403.71.132.223.146.1193894789.squirrel@calmail.berkeley.edu>
References: <2403.71.132.223.146.1193894789.squirrel@calmail.berkeley.edu>
Message-ID: <ee4042d90710312238n606a8816h9302f364713d8543@mail.gmail.com>

Oh, I think I found out why.  I have a header named K&R.h.  I guess the
submission system is buggy.  Changing its name right now.

On 10/31/07, benjlau at berkeley.edu <benjlau at berkeley.edu> wrote:
>
> When I submit, I get the following:
>
> Submitting to ee122-ra ....
> tar: ./K: No such file or directory
> sh: R.h: not found
> Submission complete.  You should be hearing from us.
>
> What's that with tar and sh?  Did the system really catch the submission?
>
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071031/b2dbcce9/attachment.html