Re: Worries about content-length

I just joined this list so I have probably missed earlier parts of
this conversation, but on a miknor point, why not just allow the
"boundary=" parameter on top level Context-Type: headers that don't
normally have this parameter instead of inventing a whole new
Content-Terminator: header?

Donald

On Tue, 9 May 1995, Patrick R. Michaud wrote:

> Date: Tue, 9 May 1995 10:54:17 -0500
> From: Patrick R. Michaud <pmichaud@tamucc.edu>
> To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject: Re: Worries about content-length
> 
> >> But if you have the files already cached and precomputed, you might
> >> as well just use Content-Length and make everyone's life easier.
> >> The problem comes for non-cachable results (such as the output of
> >> a CGI script subprocess), when the response has to be generated "live."
> >
> >But this is all really a moot point: we should be concentrating on
> >http-ng so that the existing practice, warts and all, can disappear
> >as soon as possible.
> 
> All the discussion I've seen thus far is about modifying _servers_
> to properly mark the end of the data, but my feeling is that marking
> the end of data is really the responsibility of the CGI script, not
> the server.  
> 
> CGI scripts already have to generate portions of the header anyway
> (e.g., "Content-Type: blah/blah" headers), so why not have a CGI
> script generate a "Content-Terminator:" header while it's at it and
> append the terminator itself?  Since a CGI script presumably "knows
> something" about the content it's sending, any termination string
> it generates is at least as good as, and probably better than, anything
> the server could decide to generate.
> 
> Many CGI scripts already generate "Content-Length:" headers if they can;
> it thus seems logical that marking the boundaries of the content is
> really a responsibility of the CGI script and not the server.  
> I can see some advantages of having a server generate a termination
> header on behalf of a CGI script, but I get a bad feeling about having
> servers muck around with headers (and now terminators) for content data they
> know little or nothing about.  I strongly oppose the idea of messing
> around with the content data itself (e.g., quoting marker characters)
> except as part of a Content-Transfer-Encoding scheme.
> 
> Of course, the existence of NPH-Scripts (No Parse Header) means that a CGI
> script can prevent a server from generating termination strings, at
> the (minimal) expense of generating the entire HTTP response.  
> 
> Overall, I think the idea of adding a "Content-Terminator:" header 
> and terminator strings to HTTP is a reasonable idea, and the idea of
> designating an escape-code (not as part of a Content-Transfer-Encoding)
> is a pretty bad one.  Generating content-terminator strings on behalf of a
> CGI script should be a server implementation decision, and I believe 
> that CGI scripts really ought to handle their own termination 
> (via either "Content-Length:" or "Content-Terminator:") anyway.
> 
> Pm
> 
> --------------
> Dr. Patrick R. Michaud, Assistant Professor
> Department of Computing and Mathematical Sciences
> Texas A&M University-Corpus Christi
> 6300 Ocean Drive, Corpus Christi TX 78412
> email: pmichaud@tamucc.edu   voice: 512-994-2751   fax: 512-994-2715
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)

Received on Tuesday, 9 May 1995 10:46:02 UTC