Discussions

> loading an unmanaged DLL can corrupt the managed process

What is your managed process doing and why is loading an unmanaged .dll corrupting it?

Consider an Employees table with fields:

EmployeeID <-- primary key
EmailAddress <-- unique, NULLs allowed
Office <-- unique, NULLs allowed

> allowing nulls in a unique key and then using it in a foreign key is just weird. The child insert succeeds but you effectively orphan your child rows

Not sure what you mean.

You could disable IPv6 on the server.

@Gasper that requires MAPI.

lesmemphis said:

I've been doing tests, and it turns out that my Post does not redirect when not in Internet Explorer. I need to post, because the payment gateway only receives the post and not querystring. Help!

Redirecting to POST is bad juju.

RFC 2616:

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

W3bbo said:

Use the HttpWebRequest (or just the easier-to-use WebClient) class to formulate your own request off to the gateway from within your ASP.NET application. Ensure that there aren't any cross-domain form postings too.

 

Note that POST is no more secure then GET/querystrings.

> POST is no more secure then GET/querystrings

While not any more "secure", per se, it is reasonable to expect that proxy servers will log querystrings buts not (usually) POST content.

CreamFilling512 said:

Dr Herbie said:

*snip*

Well sure, I mean biological evolution, you can call anything evolution.  Are humans still evolving biologically?  Is it even relevant anymore?

> Are humans still evolving biologically?

Yes, of course, and in the same direction we have been for a while.  The new "survival of the fittest" is "survival of the most socially networked."

blowdart said:

Matthew van Eerde said:

*snip*

Not really, it would make sense for it to be issued by an internal CA

That would work too.

cheong said:

Matthew van Eerde said:

*snip*

You need to trust the e-cert. if your SMTP server is configured to enforce SSL connection.

 

I recently run into similar problem where business requires a webservice be accessed with SSL, only that the e-cert be chosen is a self-signed one. The SSL connection object from connecter factory inside Sun webserver "helpfully" rejected it as not being trusted by all trust provider it found.

I see, this is a local SMTP server.

Well, if it's local, it makes sense for the cert to be self-signed.

I'm missing something.  How does sending mail need an SSL certificate?