Czy jar aplikacji jest pobierany przez przeglądarkę lub przez JVM?

Question

Załóżmy, że mam poniżej prostego apletu. Zastanawiam się, czy żądanie http, aby uzyskać słoik, jest dokonywane przez przeglądarkę lub przez jvm. Jeśli jest on tworzony przez jvm, czy pliki cookie i sesje przeglądarki są wysyłane na serwer?

<APPLET 
    CODE="FieldTestF.class" 
    WIDTH="100%" HEIGHT="90" 
    ARCHIVE = "FieldTestF.jar" 
    > 
This example uses an applet. 
</APPLET> 

Answer 1

Przypuszczam, że mogło to wyglądało, ale wydawało się o wiele więcej zabawy wąchać połączenie między przeglądarką a serwerem, aby znaleźć odpowiedź.

Okazuje się, że żądanie jest wykonywane przez maszynę JVM. Jest to możliwe do zaobserwowania, ponieważ:

• Agent użytkownika to Mozilla/4.0 ([OS here]) Java/[Java version here] zamiast tego, co wysyła twoja przeglądarka;
• Żądanie pliku apletu nie pochodzi z tego samego portu, z którego pochodzą żądania przeglądarki;
• Przeglądarka nie potwierdza żądań w dziennikach żądań & narzędzi programistycznych.

Przeglądarka wydaje się jednak przekazywać pliki cookie do maszyny JVM podczas wysyłania żądania HTTP, co oznacza, że ​​dane sesji powinny być dostępne.

Answer 2

JAR apletu jest pobierany przez maszynę JVM. Wszystkie aplety są powiązane z instancją obiektu URLClassloader (lub podklasy - sun.applet.AppletClassLoader w Sun JVM), która odpowiada za ładowanie wszystkich klas i zasobów wymaganych przez aplet.

Wygląda na to, że większość infrastruktury wymaganej do załadowania plików klas i zasobów jest dostępna w środowisku wykonawczym Java, a ponowne użycie tej opcji pozwoliłoby wtyczce Java w ogóle nie martwić się o dostęp do elementów przeglądarki.

Będę tu reprodukować najważniejsze części bazy kodu OpenJDK, które wykonują tę czynność. Znajdziesz ciekawe rzeczy w sposobie sun.applet.AppletPanelrunLoader():

/** 
* Load the applet into memory. 
* Runs in a seperate (and interruptible) thread from the rest of the 
* applet event processing so that it can be gracefully interrupted from 
* things like HotJava. 
*/ 
private void runLoader() { 
    if (status != APPLET_DISPOSE) { 
     showAppletStatus("notdisposed"); 
     return; 
    } 

    dispatchAppletEvent(APPLET_LOADING, null); 

    // REMIND -- might be cool to visually indicate loading here -- 
    // maybe do animation? 
    status = APPLET_LOAD; 

    // Create a class loader 
    loader = getClassLoader(getCodeBase(), getClassLoaderCacheKey()); 

    // Load the archives if present. 
    // REMIND - this probably should be done in a separate thread, 
    // or at least the additional archives (epll). 

    String code = getCode(); 

    // setup applet AppContext 
    // this must be called before loadJarFiles 
    setupAppletAppContext(); 

    try { 
     loadJarFiles(loader); // <-- this is what loads the JAR files 
     applet = createApplet(loader); 
     ... 

Również coraz przeglądarkę, aby pobrać zasoby byłyby komplikacje dla modelu zabezpieczeń Java. Częściowo wynika to z faktu, że aplety używają własnego AccessControlContext, który został dla nich skonfigurowany. Ten kontekst ma domyślny zestaw uprawnień, które są dodawane do niego podczas inicjowania apletu; zestaw zawiera SocketPermission, aby połączyć się z serwerem obsługującym bazę kodów, lub FilePermission, umożliwiając odczytowy dostęp do systemu plików zawierającego bazę kodów. Jeśli ładowanie zasobów miało zostać wykonane przez przeglądarkę, to w zależności od implementacji wtyczki, kontrole mogą po prostu nie zostać wykonane, co prowadzi do możliwego podziału modelu zabezpieczeń.

Możesz potwierdzić zachowanie ładowania JVM, patrząc na ruch sieciowy, jak wskazano w drugiej odpowiedzi. Opublikuję zrzut ekranu z Fiddlera jako potwierdzenie. Kolumna procesu wskazuje, który proces systemu operacyjnego jest odpowiedzialny za wysłanie żądania (w tym przypadku jest to program uruchamiający aplikacje Java java.exe). Przepraszamy za widoczną słabą jakość obrazu - musisz zmienić rozmiar obrazu lub otworzyć go w nowym oknie.