From ehyche at real.com  Wed Jan  2 09:16:04 2008
From: ehyche at real.com (Eric Hyche)
Date: Wed Jan  2 08:38:03 2008
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
	when URL doesn'tcontain file extension?
In-Reply-To: <2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
	<011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
	<2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
Message-ID: <010501c84d63$28a4f720$db68a8c0@EHYCHED620>


>From tracing through the code path for hxflsrc.cpp, this
looks like what *should* happen to me (see below) for shoutcast
URLs. You can verify this against your actual implementation.
This is a code trace from the HEAD, not Cay210s.

1) http filesystem is created

   	    if (HXR_OK == pPlugin2Handler->FindPluginUsingStrings(PLUGIN_CLASS, PLUGIN_FILESYSTEM_TYPE, 
	        PLUGIN_FILESYSTEMPROTOCOL, (char*)(const char*)strProtocol, NULL, NULL, pUnknown))

  in HXFileSource::Setup(), around line 464 of hxflsrc.cpp.

2) HXFileSource::ExtendedSetup gets called

        if (!theErr)
        {
	    theErr = ExtendedSetup(purl);
        }

   around line 544 of hxflsrc.cpp

3) We check to see if "Content-Type" is set in the response headers:

    // See if the caller has suggested a mime type by setting something in the response
    // headers... hxclientkit does this.
    if (m_pRequest && HXR_OK == m_pRequest->GetResponseHeaders(pResponseHeaders) && pResponseHeaders)
    {
        if (HXR_OK == pResponseHeaders->GetPropertyCString("Content-Type", pValue) &&
            pValue)

   but we haven't Init()'d or gotten the HTTP 200 OK yet, so
   this should fail and we should fall on down in ExtendedSetup().

4) We QI the file object for IHXFileMimeMapper

    // If a fileformat plugin can claim the scheme:extension
    // pair, then we don't need to try to get the file
    // mime type from the file object, since we already
    // know of file formats who can claim this URL.
    if (!bFoundMimeType && !m_pFFClaimURLEnumerator)
    {
        if (HXR_OK == m_pFileObject->QueryInterface(IID_IHXFileMimeMapper,(void**)&pFileMimeMapper))
        {

   and succeed.

5) We call IHXFileMimeMapper::FindMimeType()

	    // Init the file object, and ask for the mime type!
	    if (!theErr && HXR_OK == pFileMimeMapper->FindMimeType(pszURL, m_pMimeFinderResponse))


   
6) In filesystem/http/httpfsys.cpp, m_bInitialized should be FALSE, since
   we haven't yet called Init() on the file object. So calling FindMimeType() causes
   us to call _OpenFile() (open the socket, make the HTTP GET call, etc.)
   and we set m_bMimeResponsePending to TRUE to remember that we 
   had a call to FindMimeType().

7) Whenever we get the HTTP 200 OK and we find the "Content-Type" in the
   response, then this should result in a callback to IHXFileMimeMapperResponse::MimeTypeFound()
   in HXFileSource::CMimeFinderFileResponse::MimeTypeFound, around
   line 3553 of hxflsrc.cpp.

8) This calls HXFileSource::FinishSetup(). When we get here:

                // try and get the file mime type from the recognizer.
                if ((!m_pMimeType || *m_pMimeType == '*') && !m_pFileRecognizer && !m_pFFClaimURLEnumerator)

   in FinishSetup() we do have a valid m_pMimeType, so we
   do NOT create the recognizer, but instead here:

                AttempToLoadFilePlugin(m_pMimeType);

   try to load the file format which claims this mime type.


>From my code trace, this is what *should* happen, and 
it doesn't look to me like the recognizer should be created.

How does the code trace in your actual implementation differ
from my theoretical code trace?

Eric

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Praveen.Thimmashetty@nokia.com 
> [mailto:Praveen.Thimmashetty@nokia.com] 
> Sent: Friday, December 14, 2007 11:22 AM
> To: ehyche@real.com; client-dev@helixcommunity.org; 
> filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type 
> when URL doesn'tcontain file extension?
> 
> Hi Eric,
> I am talking about filesystem/http.
> 
> HxFilesource loads httpfilesys and looks for content type values from
> the filesystem to find out the mime type. If these values are not
> present it goes and creates the file recognizer to know the 
> mime type. 
> While handling shoutcast links, httpfilesys is providing content type
> values. Hence there is no need to create the file recognizer 
> to know the
> mime type. hence looking for the file extension is avoided.
> 
> My question is httpfilesys can provide content type values to
> Hxfilesource only after httpfilesys receives 200 OK response. Http
> response header has this value.
> But this response comes to httpfilesys only after 
> hxfilesource finishes
> with checking the content type values from httpfilesys. Hence
> hxfilesource doesn't know about the content type values at the right
> time. hxfilesource goes and creates the file recognizer to 
> know the mime
> type which will look for the file extension.
>  
> I am not clear about how exactly are we taking care of url 
> which doesn't
> have file extension.
> 
> Thanks
> Praveen  
> 
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche@real.com] 
> Sent: Thursday, December 13, 2007 6:14 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
> client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
> 
> 
> Are you saying there is no Content-Type in the HTTP response? Or that
> the Content-Type is present, but it's still not recognizing the mime
> type?
> 
> Are you using the httplite file object (filesystem/httplite) 
> or the full
> http file object (filesystem/http)?
> 
> Eric
> 
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.  
> 
> > -----Original Message-----
> > From: client-dev-bounces@helixcommunity.org
> > [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of 
> > Praveen.Thimmashetty@nokia.com
> > Sent: Thursday, December 13, 2007 5:08 PM
> > To: client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> > Subject: [Client-dev] How do we find out the mime type when URL 
> > doesn'tcontain file extension?
> > 
> > I am trying to get shout cast links(most of them don't have file 
> > extension as a part of url eg:
> > http://195.214.242.74:8000   ) 
> working on 
> > helix.
> > 
> > In httpfilesys, once we get 200 OK then content-type and mime type 
> > pair values are set by the httpfilesys on the response 
> header. Hence 
> > Hxfilesource can use these values to know the mime type 
> during extend 
> > setup.
> > 
> > HxFileSource instantiates httpfilesys during setup and while doing 
> > extended Setup, it looks for content type and mime type value pair 
> > provided by the httpfilesys. If these values are existing, 
> then Url is
> 
> > taken care without looking for file extension.
> > 
> > But in httpfilesys we get 200 OK only during finish Setup. 
> > Hence httpfilesys can provided these content type and mime 
> type value 
> > only after filesource done with extended setup.
> > 
> > how exactly are we handling this case? 
> > 
> > Thanks
> > Praveen
> > 
> > 
> 


From ehyche at real.com  Fri Jan 18 12:25:11 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Jan 18 11:43:09 2008
Subject: [Filesystem-dev] CR: Fix for bug 211207
Message-ID: <1445.24.158.112.103.1200687911.squirrel@mailone.real.com>

Description
-------------------------------------
This changes fixes a crash in the http filesystem when
a malicious chunked encoding chunk size is constructed.
This crash is detailed in bug 211207.

Files Modified
-------------------------------------
filesystem/http/httpfsys.cpp

Branches
-------------------------------------
HEAD, 150Cay, 203Cay, 204Cay, 310Atlas



=====================================
Eric Hyche, Technical Lead
RealNetworks, Inc.
ehyche@real.com
-------------- next part --------------
Index: httpfsys.cpp
===================================================================
RCS file: /cvsroot/filesystem/http/httpfsys.cpp,v
retrieving revision 1.72.2.22.2.2
diff -u -w -r1.72.2.22.2.2 httpfsys.cpp

--- httpfsys.cpp	30 Oct 2007 18:08:07 -0000	1.72.2.22.2.2
+++ httpfsys.cpp	18 Jan 2008 20:11:44 -0000
@@ -8826,13 +8826,17 @@
                 {
                     strncpy(pszTmp, pChunkedEncoding->buf, pChunkedEncoding->read );
                     pszTmp[pChunkedEncoding->read] = 0;
-                    pChunkedEncoding->size = (unsigned long)strtol(pszTmp, &errstr, 16);
-                    if( errstr == pszTmp )
+                    INT32 lSize = (INT32) strtol(pszTmp, &errstr, 16);
+                    if (lSize < 0 || errstr == pszTmp)
                     {
                         //Bad chunk size.
                         HX_ASSERT("Illegal chunk size format"==NULL);
                         rc = HXR_UNEXPECTED;
                     }
+                    else
+                    {
+                        pChunkedEncoding->size = (unsigned long) lSize;
+                    }
                     HX_VECTOR_DELETE(pszTmp);
                 }
                 else
-------------- next part --------------
Index: httpfsys.cpp
===================================================================
RCS file: /cvsroot/filesystem/http/httpfsys.cpp,v
retrieving revision 1.112
diff -u -w -r1.112 httpfsys.cpp
--- httpfsys.cpp	1 Nov 2007 02:35:30 -0000	1.112
+++ httpfsys.cpp	18 Jan 2008 20:21:39 -0000
@@ -8861,7 +8861,10 @@
         if (CE_HEADER_READY == pChunkedEncoding->state)
         {
             // parse the chunk head
-            pChunkedEncoding->size = strtoul(pChunkedEncoding->buf, &errstr, 16);
+            INT32 lSize = (INT32) strtol(pChunkedEncoding->buf, &errstr, 16);
+            if (lSize >= 0)
+            {
+                pChunkedEncoding->size = (unsigned long) lSize;
             HX_ASSERT(pChunkedEncoding->size <= pChunkedEncoding->maxChunkSizeAccepted);
             if (pChunkedEncoding->size > pChunkedEncoding->maxChunkSizeAccepted)
             {
@@ -8870,7 +8873,14 @@
                 // the limit was chosen arbitrarily, we can revise it if required.
                 rc = HXR_UNEXPECTED;
                 break;
-            };
+                }
+            }
+            else
+            {
+                // Chunk size was set to < 0, which is an error.
+                rc = HXR_FAILED;
+                break;
+            }
 
             if (pChunkedEncoding->size > 0)
             {
From gwright at real.com  Fri Jan 18 12:30:23 2008
From: gwright at real.com (Greg Wright)
Date: Fri Jan 18 11:50:04 2008
Subject: [Filesystem-dev] CR: Fix for bug 211207
In-Reply-To: <1445.24.158.112.103.1200687911.squirrel@mailone.real.com>
References: <1445.24.158.112.103.1200687911.squirrel@mailone.real.com>
Message-ID: <47910C5F.4040102@real.com>

+            INT32 lSize = (INT32) strtol(pChunkedEncoding->buf, &errstr, 16);
+            if (lSize >= 0)
+            {
+

  || pChunkedEncoding->buf==errstr ???

Looks good.
--greg.



Eric Hyche wrote:
> Description
> -------------------------------------
> This changes fixes a crash in the http filesystem when
> a malicious chunked encoding chunk size is constructed.
> This crash is detailed in bug 211207.
> 
> Files Modified
> -------------------------------------
> filesystem/http/httpfsys.cpp
> 
> Branches
> -------------------------------------
> HEAD, 150Cay, 203Cay, 204Cay, 310Atlas
> 
> 
> 
> =====================================
> Eric Hyche, Technical Lead
> RealNetworks, Inc.
> ehyche@real.com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev


From ehyche at real.com  Fri Jan 18 12:48:02 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Jan 18 12:06:02 2008
Subject: [Filesystem-dev] CR: Fix for bug 211207
In-Reply-To: <47910C5F.4040102@real.com>
References: <1445.24.158.112.103.1200687911.squirrel@mailone.real.com>
	<47910C5F.4040102@real.com>
Message-ID: <002701c85a13$6c2e9610$db68a8c0@EHYCHED620>


Thanks - I added the errstr check, and checked
into HEAD, 150Cay, 203Cay, 204Cay, and 310Atlas.

Eric

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Greg Wright [mailto:gwright@real.com] 
> Sent: Friday, January 18, 2008 3:30 PM
> To: ehyche@real.com
> Cc: filesystem-dev@lists.helixcommunity.org
> Subject: Re: [Filesystem-dev] CR: Fix for bug 211207
> 
> +            INT32 lSize = (INT32) 
> strtol(pChunkedEncoding->buf, &errstr, 16);
> +            if (lSize >= 0)
> +            {
> +
> 
>   || pChunkedEncoding->buf==errstr ???
> 
> Looks good.
> --greg.
> 
> 
> 
> Eric Hyche wrote:
> > Description
> > -------------------------------------
> > This changes fixes a crash in the http filesystem when
> > a malicious chunked encoding chunk size is constructed.
> > This crash is detailed in bug 211207.
> > 
> > Files Modified
> > -------------------------------------
> > filesystem/http/httpfsys.cpp
> > 
> > Branches
> > -------------------------------------
> > HEAD, 150Cay, 203Cay, 204Cay, 310Atlas
> > 
> > 
> > 
> > =====================================
> > Eric Hyche, Technical Lead
> > RealNetworks, Inc.
> > ehyche@real.com
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > Filesystem-dev mailing list
> > Filesystem-dev@helixcommunity.org
> > http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
> 


From vkathuria at real.com  Tue Jan 22 05:23:23 2008
From: vkathuria at real.com (Varun Kathuria)
Date: Tue Jan 22 04:39:41 2008
Subject: [Filesystem-dev] CR: Multiple changes in filesystem/local for
	porting Atlas on BREW 3.1.5
Message-ID: <022501c85cf9$f8bff180$1601a8c0@varun>

Skipped content of type multipart/alternative-------------- next part --------------
Index: full/smplfsys.cpp
===================================================================
RCS file: /cvsroot/filesystem/local/full/smplfsys.cpp,v
retrieving revision 1.47
diff -u -r1.47 smplfsys.cpp
--- full/smplfsys.cpp	18 Aug 2007 00:13:22 -0000	1.47
+++ full/smplfsys.cpp	22 Jan 2008 13:18:10 -0000
@@ -111,8 +111,8 @@
 
 #include "hxdir.h"
 
-#include 
-#include 
+#include "hlxclib/stdio.h"
+#include "hlxclib/string.h"
 
 #ifdef _MACINTOSH
 #include 
@@ -154,6 +154,23 @@
 
 #include "hxerror.h"
 
+#ifdef _BREW
+
+#ifdef AEE_SIMULATOR
+#define _WIN32
+#endif
+
+#include "AEEShell.h"
+#include "AEEStdLib.h"
+#include "AEEFile.h"
+
+#ifdef AEE_SIMULATOR 
+#undef _WIN32
+#endif
+
+extern const IShell* g_pIShell;
+#endif
+
 #ifdef _AIX
 #include "hxtbuf.h"
 #include "dllpath.h"
@@ -3070,6 +3087,18 @@
     {
 	ret = TRUE;
     }
+#elif defined(_BREW)
+    IShell*& pIShell =(IShell*&)HXGlobalPtr::Get(&::g_pIShell);
+    IFileMgr * pIFileMgr = NULL;
+    if (ISHELL_CreateInstance(pIShell, AEECLSID_FILEMGR, (void **)&pIFileMgr) == SUCCESS)
+    {			
+	if( IFILEMGR_Rename(pIFileMgr, pOldName, pNewName) == SUCCESS)
+	{
+	    ret = true;
+	}
+	IFILEMGR_Release(pIFileMgr);
+    }
+
 #else
     if (rename(pOldName, pNewName) == 0)
     {
Index: full/smplfsys.h
===================================================================
RCS file: /cvsroot/filesystem/local/full/smplfsys.h,v
retrieving revision 1.18
diff -u -r1.18 smplfsys.h
--- full/smplfsys.h	18 Aug 2007 00:13:22 -0000	1.18
+++ full/smplfsys.h	22 Jan 2008 13:18:10 -0000
@@ -50,7 +50,7 @@
 #ifndef _SMPLFSYS_H_
 #define _SMPLFSYS_H_
 
-#include 
+#include "hlxclib/stdio.h"
 
 /****************************************************************************
  * 
