[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date ][Minivend by thread ]

Re: Content-Length with HTTPS

To: steve@lwww.com, MiniVend List <minivend-users@minivend.com>
Subject: Re: Content-Length with HTTPS
From: Barry Treahy <treahy@mmaz.com>
Date: Fri, 15 Jan 1999 13:56:07 -0700
References: <369F8230.14B476AA@mmaz.com> <369F8DA2.96B1B34A@lwww.com> <369F8FCC.D5C18055@mmaz.com> <369FA0AE.A9510C81@lwww.com>
Sender: owner-minivend-users@minivend.com

******    message to minivend-users from Barry Treahy <treahy@mmaz.com>     ******

Ok... Please let me try and clear up the confusion, I've told this story so many times to so many different people,
I tend to assume everyone is on the same page.

Steve wrote:

>   Ok I am still somewhat lost here is MV running in SSL mode at all? We
> can forget the database for right now. This post problem I thought was
> isolated to the SSL part and was working ok when in a nonsecure
> environment. Also what browser are you using? There is a config
> modification that must be made for MSIE in the minivend.cfg file to work
> properly with post from MV.

For starters, both IE 4 and NS 4 behave in the exact same manner.  They both work fine when the TCP port is not
encrypted, they both fail when it is.

If there is a bullet that I need to duck from later on IE, please let me know what that is too, but that apparently
isn't the issue at the moment....

>   Basically is the problem isolated to SSL or is it across the board and
> is it the same in both Netscape and MSIE?

This is an across-the-board problem.  Please let me explain the objective.  When our user clicks the URL to
purchase on line, the URL will direct to a secured TCP port serviced by Roxen with a specific URL to fire up MV
with a custom login page and from that point forward, the entire session will remain encrypted.

With this described setup hitting a non-secure port, it works great.  I have two catalog.cfg files for testing, one
that runs the MV tests without any encryption, one with full encryption from the first breath.

On the encrypted tests, MV receives the request from the CGI and returns the correct login page.  When the screen
is filled out and submitted, MV croaks.

What I am seeing, regardless of browser, is that without encryption, the only entity information coming through is
the entity body, no entity header and it looks like:

mv_click=Login&mv_doit=return&mv_nextpage=checklogin&mv_username=xxUSERNAMExx&mv_password=xxPASSWORDxx

and MV scurries along happy.

In the encrypted tests, I also receive the entity header information preceeding the body and the data stream looks
like:

POST /cgi-bin/midwest-mi.cgi/process?9gMkhgQy;;5 HTTP/1.0
Referer: https://secure.midwest-microwave.com:27786/cgi-bin/midwest-mi.cgi/login
Connection: Keep-Alive
User-Agent: Mozilla/4.04 [en] (WinNT; U)
Host: secure.midwest-microwave.com:27786
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: RoxenUserID=0x368a7b7c; MV_SESSION_ID=9gMkhgQy:38.186.45.95
Content-type: application/x-www-form-urlencoded
Content-length: 102

mv_click=Login&mv_doit=return&mv_nextpage=checklogin&mv_username=xxUSERNAMExx&mv_password=xxPASSWORDxxand the MV
CGI process TRUNCATES the data stream in the get_entity routine because it is assuming that the total size of the
data stream is 102 bytes because of the defined CONTENT-LENGTH field but everyone I've talked to tells me that
CONTENT-LENGTH only applies to the length of the body, not the header.  Therefore the first returned string from
get_entity in the CGI process is only a 102 bytes, which stops around the letter O in the .com of the referrer and
blows the pair parsing in MV.

Does this help or clarify it at all?

TIA

Barry

> Barry Treahy wrote:
> >
> > MV is running as is Roxen.  I can access both the MV configuration interface as well as my database
> > application.  Now that I've completed some preliminary development and tests, I wanted to continue
> > development with the login interface that will be controlled on an encrypted port.  MV responds with my login
> > page through its CGI interface and when I click on the POST key, that is when all hell breaks loose and MV
> > croaks with the previously mentioned errors.
> >
> > Barry
> >
> > Steve wrote:
> >
> > >   Ok lets back up a few since I am not familiar with your previous post.
> > > Assumed in the catalog.cfg file you have listed the correct path to the
> > > SSL server? What happens when you run MV in nonsecure mode and manually
> > > type in the s to the http? If it will not run then it is server config
> > > and not MV if it does run it is MV config and we shall attack it from
> > > that point. You should be able to type in whatever url you want with or
> > > without the s and it should run. Let me know
> > >
> > > Steve
> > >
> > > Barry Treahy wrote:
> > > >
> > > > I posted a problem about 4 weeks ago about using MV with a http server
> > > > called Roxen.  It worked great except when I run MV through an https
> > > > (SSL3) port on Roxen and the suggestions from this list stated a bad
> > > > ScriptAlias.  Roxen doesn't have this type of animal, but I verified
> > > > that the equivalent was all right and proceeded to beat up the Roxen
> > > > people.
> > > >
> > > > To refresh everyones memory, I'm getting the error:
> > > >
> > > > dell400.mmaz.com - - [13/January/1999:17:57:19 +0000] -
> > > > /cgi-bin/midwest-mi.cgi/process Could not open error file : No such
> > > > file or directory
> > > > >
> > > > > to report this error:
> > > > > dell400.mmaz.com - - [13/January/1999:17:57:19 +0000] -
> > > > /cgi-bin/midwest-mi.cgi/process Runtime error: Syntax error in post
> > > > input:
> > > > > > POST /cgi-bin/midwest-mi.cgi/process?9gMkhgQy;;5 HTTP/1.0
> > > > > > Referer: https://secure.midwest-microwave.c
> > > > > >
> > > > >
> > > >
> > > > and the crux of the problem seems to be that MV sees the value of
> > > > Content-Length for the entity body and uses it for the stream read
> > > > which truncates the input stream at 102 bytes and the original stream
> > > > actual looks like:
> > > >
> > > > SSL.connection: received packet of type 23
> > > > SSL.sslfile->ssl_read_callback: application_data: 'POST
> > > > /cgi-bin/midwest-mi.cgi/process?9gMkhgQy;;5 HTTP/1.0
> > > > Referer:
> > > > https://secure.midwest-microwave.com:27786/cgi-bin/midwest-mi.cgi/login
> > > >
> > > > Connection: Keep-Alive
> > > > User-Agent: Mozilla/4.04 [en] (WinNT; U)
> > > > Host: secure.midwest-microwave.com:27786
> > > > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> > > > image/png, */*
> > > > Accept-Language: en
> > > > Accept-Charset: iso-8859-1,*,utf-8
> > > > Cookie: RoxenUserID=0x368a7b7c; MV_SESSION_ID=9gMkhgQy:38.186.45.95
> > > > Content-type: application/x-www-form-urlencoded
> > > > Content-length: 102
> > > >
> > > > mv_click=Login&mv_doit=return&mv_nextpage=checklogin&mv_username=xxUSERNAMExx&mv_password=xxPASSWORDxx'
> > > >
> > > > SSL3:ssl_accept_callback(X)
> > > >
> > > > When I do the same test WITHOUT encryption, the header stuff does not
> > > > appear and MV works fine.  The questions is, whose fault is this???
> > > > It seems that after beating on the Roxen folks for the past 3 weeks,
> > > > it may be MV fault after all since the stream isn't being read
> > > > correctly!  Can anyone please offer some helpful insights??
> > > >
> > > > TIA
> > > >
> > > > Barry

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list

References:
- Content-Length with HTTPS
  - From: Barry Treahy <treahy@mmaz.com>
- Re: Content-Length with HTTPS
  - From: Barry Treahy <treahy@mmaz.com>

Prev by Date: Re: Content-Length with HTTPS
Next by Date: Is this just me?
Prev by thread: Re: Content-Length with HTTPS
Next by thread: Is this just me?
Index(es):
- Date
- Thread