[Info-vax] wrong file format

[Arne Vajhøj]

On 1/1/2021 12:03 AM, Dave Froble wrote:
> On 12/31/2020 8:30 PM, Arne Vajhøj wrote:
>> On 12/31/2020 8:13 PM, Dave Froble wrote:
>>> On 12/31/2020 3:05 PM, Arne Vajhøj wrote:
>>>> On 12/31/2020 2:09 PM, Bill Gunshannon wrote:
>>>>> On 12/31/20 1:58 PM, Phillip Helbig (undress to reply) wrote:
>>>>>> In article <rsl4jt$7ui$1 at dont-email.me>, Dave Froble
>>>>>> <davef at tsoft-inc.com> writes:
>>>>>>>> I would love to know where the original file that started this
>>>>>>>> discussion came from and how it ended up on a VMS Systems.
>>>>>>>
>>>>>>> Well, yes, Phillip is rather good at providing mysteries for us to
>>>>>>> figure out.  It sure would have been reasonable for him to lay out
>>>>>>> precisely the entire sequence of events from start to finish.
>>>>>>
>>>>>> That would take more time than it is worth.  Suffice it to say that
>>>>>> they
>>>>>> were uploaded via a shaky http connection.
>>>>>
>>>>> Believe it or not, that goes a long way towards explaining what
>>>>> happened and what you got.  HTTP does not have a concept of
>>>>> ASCII/BINARY.  Transferring "text" files from none VMS systems
>>>>> to VMS systems using HTTP is bound to result in at least the
>>>>> CR+LF|LF+CR|CR|LF problem and, depending on the sending system
>>>>> even stranger results are possible,
>>>>
>>>> HTTP has the Content-Type header.
>>>
>>> Most of the "optional" HTTP headers are just that, optional, and I've
>>> seen way too many headers that were sorely lacking in sufficient
>>> header data.
>>
>> I think that header is pretty likely to be there.
>>
>> HTTP RFC says:
>>
>> <quote>
>> Any HTTP/1.1 message containing an entity-body SHOULD include a
>> Content-Type header field defining the media type of that body.
>> </quote>
> 
> Well, there is that word, "should" ....

I believe that is the second strongest requirement after MUST.

> When I found incoming HTTP packages without the "Content_Length" to tell 
> the size of the detail part of the package, I was rather disgusted.  So 
> easy to insure the amount of data, and then not used.  I ended up 
> rejecting such packages.  I felt and still feel fully justified.

Content-Length is more complicated than Content-Type.

RFC:

<quote>
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
</quote>

<quote>
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given,
the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length.
</quote>

>> And most web stuff will not work without that header.
> 
> You might be surprised at what some might do.
> 
>> Any web server will have to send that or be considered
>> totally broken.
> 
> Well, there you are wrong, because I've seen it.

What server does not send Content-Type?

Arne